1 原始构成
synchronized是关键字属于JVM层面
monitorenter(底层是通过monitor对象来完成,其实wait/notify等方法也依赖于monitor对象只有在同步块或方法中才能调wait/notify等方法)
monitorexit
Lock是具体类(java.concurrent.locks.lock)是api层面的锁
2 使用方法
synchronized 不需要用户去手动释放锁,当synchronized代码执行完后系统会自动让线程释放对锁的占用
ReentrantLock则需要用户手动释放锁若没有主动释放锁,就有可能导致出现死锁现象
需要lock()和unlock()方法配合try/finally语句来完成
3 等待是否可中断
synchronized 不可中断,除非抛出异常或者正常运行完成
ReentrantLock可中断,1.设置超时方法tryLock(long timeOut,TimeUnit unit)
2. lockInterruptibly()放代码块中,调用interrupt()方法可中断
4 加锁是否公平
synchronized 非公平锁
ReentrantLock 两者都可以,默认非公平锁,构造方法可以传入boolean值,true为公平锁,false为非公平锁
5 锁绑定多个条件Condition
synchronized没有
ReentrantLock用来实现分组唤醒需要唤醒的线程们,可以精确唤醒,而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程
公平锁和非公平锁
公平锁:
是指多个线程按照申请锁的顺序来获取锁。
非公平锁:
是指多个线程获取锁的顺序并不是按照申请锁的顺序,有可能后申请的线程比先申请的线程优先获取锁,在高并发的情况下,有可能会造成优先级反转或者饥饿现象。
两者的区别:
公平锁/非公平锁:并发包中ReentrantLock的创建可以指定构造函数的boolean类型来得到公平锁或非公平锁,默认是非公平锁。
两者区别:
公平锁,就是很公平,在并发环境中,每个线程在获取锁时会先查看此锁维护的等待队列,如果为空,或者当前线程是等待队列的第一个,就占有锁,否则就会加入到等待队列中,以后会按照FIFO的规则从队列中取到自己
非公平锁比较粗鲁,上来就直接尝试占有锁,如果尝试失败,就再采用类似公平锁那种方式。