JUC并发包——Lock锁解决生产者消费者问题

原来的写法

package com.bjsxt.commu1; import java.util.ArrayList; import java.util.List; /**  * 商品工厂  */ public class ProductFactory {     private List<String> list = new ArrayList<String>();     private int max = 10;     public ProductFactory() {     }     public ProductFactory(int max) {         this.max = max;     }     /**      * 生产商品      * @param productName      */     public synchronized void produce(String productName){         //仓库满，就不在生产         while (list.size()==max){             System.out.println(Thread.currentThread().getName()+"仓库已满,目前商品数量"+list.size());             try {                 this.wait();//释放锁，进入等待队列             } catch (InterruptedException e) {                 e.printStackTrace();             }         }         //生产商品         list.add(productName);         System.out.println(Thread.currentThread().getName()+"生产商品:" + productName+",目前商品数量"+list.size());         //唤醒消费者，通知消费者消费         /*没有指定唤醒哪个线程，消费者和生产者处在同一个等待队列，             可能唤醒一个生产者,我们让生产者再判断，生产者发现仓库满的，继续沉睡，             再唤醒别的生产者，我们让别的生产者再判断，别的生产者再判断发现仓库满的，             别的生产者继续沉睡，直到唤醒一个消费者。             如何让他再回去判断？把判断做成一个循环，不断反复判断，             不符合就跳出循环，符合就执行循环继续沉睡。          */         this.notify();     }     /**      * 消费商品      */     public synchronized void consume() {         while (list.size() == 0) {             System.out.println(Thread.currentThread().getName() + "仓库已经没有库存了，目前商品的数量：" + list.size());             try {                 this.wait();//释放锁，进入等待队列             } catch (InterruptedException e) {                 e.printStackTrace();             }         }         String productName = list.remove(0);         System.out.println(Thread.currentThread().getName() + "消费商品：" + productName + "，目前商品的数量：" + list.size());         //唤醒生产者，通知生产者生产         this.notify();     } }

test

package com.bjsxt.test; import com.bjsxt.commu1.ConsumeRunnable; import com.bjsxt.commu1.ProduceRunnable; import com.bjsxt.commu1.ProductFactory; public class Test {     public static void main(String[] args) {         //创建并启动多个生产者和消费者线程         final ProductFactory factory = new ProductFactory(30);         for (int i = 0; i < 20; i++) {             new Thread(new Runnable() {                 @Override                 public void run() {                     int j=1;                     while (true){                         factory.produce("商品"+j);                         j++;                         try {                             Thread.sleep(500);                         } catch (InterruptedException e) {                             e.printStackTrace();                         }                     }                 }             }, "生产者" + i).start();         }         for (int i = 0; i < 10; i++) {             new Thread(new Runnable() {                 @Override                 public void run() {                     while (true){                         //消费一个商品                         factory.consume();                         try {                             Thread.sleep(500);                         } catch (InterruptedException e) {                             e.printStackTrace();                         }                     }                 }             }, "消费者" + i).start();         }     } }

 

synchronized定义在方法上表示给方法加锁，除了这个线程其他线程访问不了。

wait阻塞线程，并释放锁，其他线程就可以访问了。

notify唤醒线程。随机唤醒一个等待中的线程。

 

Lock锁实现

         实现生产者和消费者不同等待队列。

         只能手动开启，手动关闭，不关就一直阻塞，别的线程拿不到锁就进不来。

         只管同步，不管通信。

        private Lock lock = new ReentrantLock();

开启

lock.lock();

关闭

lock.unlock();

 

想通信怎么办？

我们定义生产者一个队列，消费者一个队列。

        private Condition produceCond = lock.newCondition();

        private Condition consumeCond = lock.newCondition();

 

生产

生产者线程阻塞

        produceCond.await();

 

唤醒消费者线程

        consumeCond.signal();

 

消费

消费者阻塞

        consumeCond.await();

 

唤醒生产者

        //唤醒生产者，通知生产者生产

        produceCond.signal();

 

//通知生产者

//唤醒所有的生产者，但是只有一个生产者线程首先获取Lock,然后进入就绪队列，通过调度获得CPU     

produceCond.signalAll();

 

其他醒来的生产者线程没拿到锁，继续陷入阻塞。

 

Lock锁也在并发包下。

Lock锁接口，我们用过他的一个实现类ReentrantLock。

他还有别的实现类，

ReentrantReadWriteLock实现ReadWriteLock类，它关联了两个内部类(ReadLock和WriteLock)，两个内部类都实现了Lock接口。

 

Re-entrant-Lock 可冲入锁 之前的Synchronized也是可重入锁。

 

lock对象有哪些方法？

public   interface   Lock {       void   lock();       void   lockInterruptibly()   throws   InterruptedException;       boolean   tryLock();       boolean   tryLock(  long   time, TimeUnit unit)   throws   InterruptedException;       void   unlock();       Condition newCondition(); }

 

获得锁

lock.lock();

 

lock.tryLock();

 tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。

 

lock.tryLock(10,TimeUnit.MILLISECONDS);10毫秒，seconds时间单位秒, MILLISECONDS毫秒

tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。

 

 

lock.lockInterruptibly();可以中断

 lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。

 

解锁只有一种方式

lock.unlock();

 

lock.newCondition();创造等待队列。

 

ReentrantLock分为“公平锁”和“非公平锁”。它们的区别体现在获取锁的机制上是否公平。“锁”是为了保护竞争资源，防止多个线程同时操作线程而出错，ReentrantLock在同一个时间点只能被一个线程获取(当某线程获取到“锁”时，其它线程就必须等待)；ReentraantLock是通过一个FIFO的等待队列来管理获取该锁所有线程的。

 

在“公平锁”的机制下，线程依次排队获取锁；而“非公平锁”在锁是可获取状态时，不管自己是不是在队列的开头都会获取锁。

 

ReentrantLock默认是非公平锁。

 

3.ReadWriteLock 读写锁

ReadWriteLock rwl =new ReentrantReadWriteLock();//默认也是非公平锁 也是可重入锁

一个用来获取读锁，一个用来获取写锁。也就是说将文件的读写操作分开，分成2个锁来分配给线程，从而使得多个线程可以同时进行读操作。下面的ReentrantReadWriteLock实现了ReadWriteLock接口。

 

Lock readLock = rwl.readLock();//多次返回的都是同一把读锁，同一把写锁         Lock readLock2 = rwl.readLock();         Lock writeLock = rwl.writeLock();         System.out.println(readLock==readLock2);

 

4.ReentrantReadWriteLock

　　ReentrantReadWriteLock里面提供了很多丰富的方法，不过最主要的有两个方法：readLock()和writeLock()用来获取读锁和写锁。

　   ReadWriteLock是一个接口。

      ReentrantReadWriteLock是它的实现类，ReentrantReadWriteLock包括内部类ReadLock和WriteLock，这两个内部类实现了Lock接口。

 

自己实践的理解：

         读锁和写锁互斥，

读线程拿到读锁正在读的时候，写线程阻塞，

读线程拿到读锁正在读的时候，因为读锁共享，所以其他读线程也可以在这个读锁未释放的时候拿他同时一起读，所有读锁都读完解锁的时候，写线程才可以进入，

所有读锁都读完解锁的时候，下一轮读线程读取前，如果有写线程正在等待，写线程优先级最高，

写线程拿到锁正在写的时候，读线程不能进入，

写线程拿到锁正在写的时候，其他写线程不能进入，

该写线程写完释放锁的时候，如果同一个线程又有任务，它的优先级比其他写线程和读线程的优先级都高，直接又会调用它，其他线程需要等CPU调度的时候随着时间片轮不到的次数增多来提升优先级才能进入，一般次数比较多，优先级比较难提升。

         线程时间片轮到的次数越多，优先级越低，

         其他等待线程执行一次后，优先级回到默认值，

         优先级高的线程让出一次后，优先级回到默认值。

 

三、Lock和synchronized的选择

　总结来说，Lock和synchronized有以下几点不同：

　　1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；

　　2）synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；

　　3）Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；

　　4）通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。

　　5）Lock可以提高多个线程进行读操作的效率。

　　在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

 

Condition条件

Condition是在Java 1.5中才出现的，它用来替代传统的Object的wait()、notify()实现线程间的协作，相比使用Object的wait()、notify()，使用Condition1的await()、signal()这种方式实现线程间协作更加安全和高效。

 

它的更强大的地方在于：能够更加精细的控制多线程的休眠与唤醒。对于同一个锁，我们可以创建多个Condition，在不同的情况下使用不同的Condition

一个Condition包含一个等待队列。一个Lock可以产生多个Condition，所以可以有多个等待队列。

在Object的监视器模型上，一个对象拥有一个同步队列和等待队列，而Lock（同步器）拥有一个同步队列和多个等待队列。

 

Object中的wait(),notify(),notifyAll()方法是和"同步锁"(synchronized关键字)捆绑使用的；而Condition是需要与"互斥锁"/"共享锁"捆绑使用的。

 

调用Condition的await()、signal()、signalAll()方法，都必须在lock保护之内，就是说必须在lock.lock()和lock.unlock之间才可以使用

• Conditon中的await()对应Object的wait()；
• Condition中的signal()对应Object的notify()；
• Condition中的signalAll()对应Object的notifyAll()。

await

 

void await()  throws InterruptedException

造成当前线程在接到信号或被中断之前一直处于等待状态。

与此 Condition 相关的锁以原子方式释放，并且出于线程调度的目的，将禁用当前线程，且在发生以下四种情况之一 以前，当前线程将一直处于休眠状态：

• 其他某个线程调用此 Condition 的 signal() 方法，并且碰巧将当前线程选为被唤醒的线程；或者
• 其他某个线程调用此 Condition 的 signalAll() 方法；或者
• 其他某个线程中断当前线程，且支持中断线程的挂起；或者
• 发生“虚假唤醒”

在所有情况下，在此方法可以返回当前线程之前，都必须重新获取与此条件有关的锁。在线程返回时，可以保证 它保持此锁。

signal

void signal()

唤醒一个等待线程。

如果所有的线程都在等待此条件，则选择其中的一个唤醒。在从 await 返回之前，该线程必须重新获取锁。

---

signalAll

 

void signalAll()

唤醒所有等待线程。

如果所有的线程都在等待此条件，则唤醒所有线程。在从 await 返回之前，每个线程都必须重新获取锁。