高并发下悲观锁与乐观锁的选择问题

Question

说说我的看法，不对的地方请指正。

乐观锁的实现原理是cas操作，java中轻量级锁也是基于cas实现的。

悲观锁最大的问题就是阻塞问题。

在深入理解java虚拟机中提到，轻量级锁一般情况下是优于重量级锁（互斥锁）的；如果在高并发锁竞争比较激烈的情况下轻量级锁会由于长时间自旋消耗cpu 从而使得轻量级锁的性能比传统的重量级锁更慢。那么乐观锁中也有自旋和cas，所以高并发下乐观锁好像不是一种好的解决方案。

但是有些博文中提到 高并发下使用乐观锁更合适
比如这篇文章中就提到高并发数据库访问使用乐观锁
http://blog.csdn.net/amqvje/a...

问题1，高并发下如何选择？

问题2 乐观锁有什么缺点？ 为什不都使用乐观锁。高并发下都是使用乐观锁，如果并发量不高，使用乐观锁感觉更不是问题

Answer 1

简单的来说，一般情况下，乐观锁适合只有读没有写的操作，悲观锁适合于读写混合的操作。如果写操作非常简单短小，比如增加访问人数，也可以用乐观锁，或者不需要确保读到的数据是最新的时候。80%的情况下使用乐观锁确实是比较好的选择。 CAS依靠硬件CPU指令支持去实现原子级操作，所以高并发的情况下一般会更快，但是这个快不是没有缺点的，缺点就是有读也有写的时候，CPU缓存失效率可能会增加，除非你的CPU是单核的（非Intel平台的嵌入式）。 总而言之，要提升高并发性能，还是要实际测量出的数据说明问题，我上面提到的都是理论。希望对你有帮助。

Answer 2

没工作之前我也是和题主相同的想法，实际工作中，其实两者差别不大，真正高并发下系统耗时的地方永远是网络连接，数据库查询以及线程的主动睡眠，锁带来开销基本可以忽略不计

Answer 3

关键问题在于，事实是悲观的还是乐观的？ 假如你的资源竞争很激烈，并且无法共享的话，乐观锁不过是让大量请求的希望落空罢了。 假如你的资源没什么竞争（这个和并发高低没必然的关联，业务的影响更大），那悲观锁意味着不必要地加锁。如果原本是可共享的资源（比如资源支持多个只读方），那么悲观锁意味着失去原本的可以使用的时间。 在深入理解java虚拟机中提到，轻量级锁一般情况下是优于重量级锁（互斥锁）的；如果在高并发锁竞争比较激烈的情况下轻量级锁会由于长时间自旋消耗cpu 从而使得轻量级锁的性能比传统的重量级锁更慢。那么乐观锁中也有自旋和cas，所以高并发下悲观锁好像不是一种好的解决方案。 我并不了解 JVM。不过「乐观锁中也有自旋和cas」是什么意思？cas 就是自旋锁的一种实现方式，为什么要并列呢？「也」是什么意思？悲观锁是个阻塞操作，没有自旋，也不会持续消耗 CPU 的。