JUC与jvm(2)锁机制/线程通信
8种情况讨论java synchronized的锁机制
代码如下
public class Lock8Demo {
public static void main(String[] args) throws Exception {
Phone phone = new Phone();
Phone phone2 = new Phone();
new Thread(()->{
try {
phone.sendSMS();
} catch (Exception e) {
e.printStackTrace();
}
},"A").start();
Thread.sleep(100);
new Thread(()->{
try {
//phone.sendEmail();
//phone.sayHello();
phone2.sendEmail();
} catch (Exception e) {
e.printStackTrace();
}
},"B").start();
}
}
class Phone{
public synchronized void sendSMS() throws InterruptedException {
//TimeUnit.SECONDS.sleep(4);
System.out.println("sms");
}
public synchronized void sendEmail() throws Exception{
System.out.println("mail");
}
public void sayHello() throws Exception{
System.out.println("hello");
}
}
问题:
-
标准访问,先短信还是邮件?
因main中有sleep方法,先sms;
-
在短信中添加TimeUnit.SECONDS.sleep(4);后,先短信还是邮件?
结果:等待4s,随后输出sms,再mail
原因:synchronized直接锁了这个对象的所有含synchronized的资源;故当线程A再运行sendSMS方法时,线程B无法访问sendEmail方法,出现这种效果
synchronized :锁的是当前的这个对象
-
新增普通方法,先短信还是普通方法?
结果:普通方法,等4s,再短信;
原因:synchronized不锁定,不含synchronized的资源
-
两部手机,先短信还是邮件?
结果,先邮件,后短信
原因:不涉及synchronized锁,只因为短信要sleep 4秒钟;根本原因,见第2点加黑字;此时非同一把锁;
-
将短信和邮件设为静态同步方法,同部手机,先短信还是邮件?
结果和原因同2;
-
将短信和邮件设为静态同步方法,两部手机,先短信还是邮件?
结果同2:
原因:static修饰后,该方法属于类,此时的synchronized锁的是静态资源,故而锁住了该类的方法,无论2部手机还是同部手机,实际上是一把锁,这个synchronized锁住的是类Phone,而非对象;
此时情况,又称为全局锁;另一种锁叫对象锁,即情况2;
-
1个静态同步方法,1个普通同步方法,同一部手机,先短信还是邮件?
结果:先邮件,后短信;
原因:虽然是同个对象,但实际是两把锁,一把全局锁Class对象,一把对象锁this对象;故而可以分开访问,
-
1个静态同步方法,1个普通同步方法,两部手机,先短信还是邮件?
结果:同7,原理不再赘述;
线程通信
主要是用
//synchronized锁用:
this.notifyAll();
this.wait();
进行,相关使用参见api等文档;
多线程之间的虚假唤醒
举个例子,我们现在有一个生产者-消费者队列和三个线程。
1) 1号线程从队列中获取了一个元素,此时队列变为空。
2) 2号线程也想从队列中获取一个元素,但此时队列为空,2号线程便只能进入阻塞(cond.wait()),等待队列非空。
3) 这时,3号线程将一个元素入队,并调用cond.notify()唤醒条件变量。
4) 处于等待状态的2号线程接收到3号线程的唤醒信号,便准备解除阻塞状态,执行接下来的任务(获取队列中的元素)。
5) 然而可能出现这样的情况:当2号线程准备获得队列的锁,去获取队列中的元素时,此时1号线程刚好执行完之前的元素操作,返回再去请求队列中的元素,1号线程便获得队列的锁,检查到队列非空,就获取到了3号线程刚刚入队的元素,然后释放队列锁。
6) 等到2号线程获得队列锁,判断发现队列仍为空,1号线程“偷走了”这个元素,所以对于2号线程而言,这次唤醒就是“虚假”的,它需要再次等待队列非空。
造成原因:
private int i = -1;
public void needWaite(){
if(i>0){
//point
this.wait()
}
i--;
}
若在point处进行了waite,那么当再度唤醒时,是否还需要进行一次判断??
用if,则不会再次判断,可能会导致其他线程,已经处理过i,例如此时i=2;但因没有再次校验;会导致运行结果并不想要;
问题解决:
参见API文档:
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}
wait时,因使用while循环;保证再次判断;
jdk1.8 Lock锁之间的通信
如前文所述:
新锁:ReentrantLock(java.util.concurrent.locks);如何通信?
private Lock lock = new ReentrantLock();
private Condition condition = lock.newCondition();
condition.await();
condition.signal();
condition.signalAll();