原来的写法
package com.bjsxt.commu1;
|
test
|
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接口。
|
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之间才可以使用
await
void await() throws InterruptedException
造成当前线程在接到信号或被中断之前一直处于等待状态。
与此 Condition 相关的锁以原子方式释放,并且出于线程调度的目的,将禁用当前线程,且在发生以下四种情况之一 以前,当前线程将一直处于休眠状态:
在所有情况下,在此方法可以返回当前线程之前,都必须重新获取与此条件有关的锁。在线程返回时,可以保证 它保持此锁。
signal
void signal()
唤醒一个等待线程。
如果所有的线程都在等待此条件,则选择其中的一个唤醒。在从 await 返回之前,该线程必须重新获取锁。
signalAll
void signalAll()
唤醒所有等待线程。
如果所有的线程都在等待此条件,则唤醒所有线程。在从 await 返回之前,每个线程都必须重新获取锁。