Java多线程之内置锁与显式锁

Java中带有通过Synchronized实现的内嵌锁，和ReentrantLock实现的显示锁，这两种锁各有各的益处，算是互有补充。

Synchronized

内置锁获得锁和传递锁是隐式的，进入synchronized修饰的代码就获取锁sqlite3多线程死锁，走出相应的代码就释放锁。

通信

与Synchronized配套使用的通信方式一般有wait(),notify()。

wait()方法会立刻释放当前锁，并开启等待状态，等待到相应的notify并再次取得锁之后才会继续执行；notify()不会立刻立刻释放锁，必须要等notify()所程执行完synchronized块中的所有代码就会释放。用如下代码来进行验证：

运行结果

可见读线程开始运行，开始wait过后，写线程才拿到锁；写线程走出同步块而不是notify过后，读线程才wait结束，亦即获得锁。所以notify不会释放锁，wait会释放锁。

值得一提的是，notifyall()会通知等待队列中的所有线程。

编码

编码方式非常简洁，单一，不必显示的获取锁，释放锁，能增加因疏忽忘记释放锁的出错。使用方式如下：

synchronized(object){

}

灵活性

内置锁在开启同步块时，采取的是无限期待的思路，一旦开始期待，就既不能中断也不能取消，容易造成饥饿与死锁的问题

在句柄读取notify方法时，会随机选取相应对象的期待队列的一个线程将其激活，而不是按照FIFO的方法，如果有强烈的公平性要求，比如FIFO就能够满足

性能

Synchronized在JDK1.5及之前性能（主要指吞吐率）比较差，扩展性也不如ReentrantLock。但是JDK1.6之后，修改了管理内置锁的算法，使得Synchronized和标准的ReentrantLock性能差距不大。

ReentrantLock

ReentrantLock是显示锁，需要显示进行 lock 以及 unlock 操作。

通信

与ReentrantLock搭配的通行模式是Condition，如下：

Condition是被绑定到Lock上的，必须使用lock.newCondition()才能创建一个Condition。从后面的代码可以看出，Synchronized能推动的通信手段，Condition都可以推动，功能类似的代码写在同一行中。

而Condition的优秀之处在于它可以为多个线程间构建不同的Condition，比如对象的读/写Condition，队列的空/满Condition，在JDK源码中的ArrayBlockingQueue中就使用了这个特点：

编码

相比于Synchronized要复杂一些，而且一定要记得在finally中释放锁而不是其他地方，这样就能确保一旦出了异常也能释放锁。

灵活性

lock.lockInterruptibly() 可以并且线程在期待锁是支持响应中断；lock.tryLock() 可以促使线程在期待一段时间过后假如还未获得锁就中止等待而非经常期待。有了这两种模式就可以更好的建立获取锁的重试机制，而非过度一直等待，可以更好的防止饥饿和死锁问题

ReentrantLock可以作为公平锁（非默认的），所谓公平锁就是锁的期待队列的FIFO，不过公平锁会带给性能损耗，如果不是必须的不建议使用。这和CPU对指令进行重排序的原因是相同的，如果试图的依照代码的书写顺序来执行指令，就会耗费许多时钟周期，达不到最大利用率

性能

虽然Synchronized和标准的ReentrantLock性能差距不大，但是ReentrantLock还提供了一种非互斥的读写锁，

也就是不强行每次最多只有一个线程能持有锁，它会避免“读/写”冲突，“写/写”冲突，但是不会排除“读/读”冲突sqlite3多线程死锁，

因为“读/读”并不影响数据的完整性，所以可以多个读线程同时持有锁，这样在读写比较高的状况下，性能会有多大的提高。

下面用两种锁分别实现的轮询安全的linkedlist：

读写锁测试代码：

同步锁测试代码：

结果：

可见读写锁的确是优于纯碎的互斥锁

总结

内置锁最大优点是简单易用，显示锁最大优点是用途丰富，所以能用内置锁就用内嵌锁，在外置锁功能不能满足之时在考量显示锁。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-121974-1.html