java线程之线程同步与线程通信(Synchronized/Lock)-CSDN博客

一、线程同步

线程同步通常是指做同类事情的各个线程，对一个同共享变量不能同时访问。

进程同步的几种方式：

1、同步代码块

synchronized(Object){

需要被同步的代码块

}

如果将 run方法中的代码全部放到同步块里，那么就成了单线程，失去了意义。

同步代码块的优缺点：

好处：解决多线程的安全问题。

弊端：每个线程只要获得CPU执行权，每次都要判断锁，较为消耗资源。越安全越麻烦！有利必有弊！

2、同步函数

同步函数没有显式指定同步锁，那么它是怎样实现同步的呢？函数需要被对象调用，那么函数都有一个所属对象的引用——this,所以同步函数

使用的锁就是this。

现在知道了普通函数的同步锁是this,那么静态方法不是由对象调用，没有this，那么它使用的同步锁又是什么呢？它的锁是类所对应的Class字节

码文件对象。

经试难，两个线程分别执行上面以Ticket.class为锁的同步代码块和静态方法，这两个线程成功地实现了进程同步！这说明静态方法确实是以字节码文件

对象为同步锁的。

线程同步需要明确的问题：

1、首先明确哪些代码是多线程运行代码

2、明确哪些数据是共享数据

3、明确多线程运行代码中哪些语句是操作共享数据的

线程同步

二、线程通信

线程通信通常是指做不同类事情的各个线程，除了不能同时访问共享变量，还要在一定条件下相互通信。比如

生产者消费者。在产品池为空时，消费者阻塞，此时如果生产者生产一个产品，则通知消费者可以进行消费；

当产品池满时，生产者阻塞，此时如果消费者消费掉一个产品，则通知生产者可以进行生产。对产品个数的

操作除了不能同时进行外，还要关注产品个数为0和为n 的情况。这就是线程通信与线程同步不同之处。

1、多个生产者多个消费者，使用notity 导致全部等待问题

使用notify唤醒不该唤的线程，该唤醒的线程却没有唤醒，导致死锁。比如两个生产者A，B和两个消费者M，和N。当产品数为0时，假设某一时刻，消费者M消费了一个产品，此时A，B和N同时都在等待，并且N在CPU队列中最前面，当调用notify后N线程被唤醒，但此时产品数为0，此时消费者N就会处于等待。理应将对方唤醒，但唤醒的本方，就这样导致了四个线程全部等待。

这时，如果使用notifyAll就可以解决。将所有线程都唤醒，此时就不会出现全部都等待的状况。

2、停止线程

只有一种方式，即run方法结束。只要控制住循环，就可以让方法结束，也就是线程结束。iterrupte 将处于冻结状态的线程，强制地恢复到运行状态中来。也就是清除线程的

冻结状态。

三、Lock 锁

Lock类是jdk1.5中新加入的同步锁的升级解决方案。Lock 实现提供了比使用 synchronized 方法和语句可获得的更广泛的锁定操作。此实现允许更灵活的结构，可以具有差别很大的属性，可以支持多个相关的Condition 对象。

锁是控制多个线程对共享资源进行访问的工具。通常，锁提供了对共享资源的独占访问。一次只能有一个线程获得锁，对共享资源的所有访问都需要首先获得锁。不过，某些锁可能允许对共享资源并发访问，如ReadWriteLock 的读取锁。

synchronized 方法或语句的使用提供了对与每个对象相关的隐式监视器锁的访问，但却强制所有锁获取和释放均要出现在一个块结构中：当获取了多个锁时，它们必须以相反的顺序释放，且必须在与所有锁被获取时相同的词法范围内释放所有锁。

虽然 synchronized 方法和语句的范围机制使得使用监视器锁编程方便了很多，而且还帮助避免了很多涉及到锁的常见编程错误，但有时也需要以更为灵活的方式使用锁。例如，某些遍历并发访问的数据结果的算法要求使用 "hand-over-hand" 或 "chain locking"：获取节点 A 的锁，然后再获取节点 B 的锁，然后释放 A 并获取 C，然后释放 B 并获取 D，依此类推。Lock 接口的实现允许锁在不同的作用范围内获取和释放，并允许以任何顺序获取和释放多个锁，从而支持使用这种技术。

随着灵活性的增加，也带来了更多的责任。不使用块结构锁就失去了使用 synchronized 方法和语句时会出现的锁自动释放功能。在大多数情况下，应该使用以下语句：

     Lock l = ...; 
     l.lock();
     try {
         // access the resource protected by this lock
     } finally {
         l.unlock();
     }