JUC与JVM(2)锁机制/线程通信

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");
    }
}

问题：

1. 标准访问，先短信还是邮件？

   因main中有sleep方法，先sms；

2. 在短信中添加TimeUnit.SECONDS.sleep(4);后，先短信还是邮件？

   结果：等待4s，随后输出sms，再mail

   原因：synchronized直接锁了这个对象的所有含synchronized的资源；故当线程A再运行sendSMS方法时，线程B无法访问sendEmail方法，出现这种效果

   synchronized ：锁的是当前的这个对象

3. 新增普通方法，先短信还是普通方法？

   结果：普通方法，等4s，再短信；

   原因：synchronized不锁定，不含synchronized的资源

4. 两部手机，先短信还是邮件？

   结果，先邮件，后短信

   原因：不涉及synchronized锁，只因为短信要sleep 4秒钟；根本原因，见第2点加黑字；此时非同一把锁；

5. 将短信和邮件设为静态同步方法，同部手机，先短信还是邮件？

   结果和原因同2；

6. 将短信和邮件设为静态同步方法，两部手机，先短信还是邮件？

   结果同2:

   原因：static修饰后，该方法属于类，此时的synchronized锁的是静态资源，故而锁住了该类的方法，无论2部手机还是同部手机，实际上是一把锁，这个synchronized锁住的是类Phone，而非对象；

   此时情况，又称为全局锁；另一种锁叫对象锁，即情况2；

7. 1个静态同步方法，1个普通同步方法，同一部手机，先短信还是邮件？

   结果：先邮件，后短信；

   原因：虽然是同个对象，但实际是两把锁，一把全局锁Class对象，一把对象锁this对象；故而可以分开访问，

8. 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();