java 乐观锁 会不会超生死锁
从定义上来说乐观锁不会死锁，因为它根本就没有真正锁的过程，它的原理是在过程开始之前记录住几个key的版本号，再结束提交的时候检查版本号，如果版本号变动了，就回滚掉整个过程重来，它本身并没有可以死锁的机制，因为不像悲观锁那样有阻塞的过程。但是有几个问题，一个是有可能提交时的版本号检查这一步是通过悲观锁进行的，那这一步的实现自己可能会死锁；二是如果跟其他锁联动了，可能会间接导致死锁；三是某些实现中如果用到了两步提交，如果不排好序按顺序进行提交，可能会出现两个请求不停地互相回滚掉，再次运行再次冲突，再次互相回滚掉，这种一般不叫做死锁，因为有可能尝试一定次数之后自己解开了，但是仍然会严重影响执行效率并浪费大量的CPU时间。有些地方也叫做活锁（livelock）。然后是你举的这个程序的例子，因为这个列表要返回，返回值可能会给其他线程使用，所以为了谨慎直接创建一个线程安全的List不算错，保不准后面的其他过程中，会不会往这个List中追加对象。不过要是我设计的话肯定不会有这个接口，为什么会有一个接口专门排序两个对象，而不是抽象度更高的任意多个对象……
■网友
【java 乐观锁 会不会超生死锁】 
仅供参考
推荐阅读
- dart这编程语言现在发展怎么样了，语法与Java，c#很相似，甚至更简洁
- 行业投资阶段服务类的B2B项目，两个产品方向，但联动，在商业计划书中两个产品并存会不会不聚焦
- Java工程师和C++工程师在工作上有啥区别哪个更适合自身发展
- 阿喵汽车|车子一直用S档，开运动模式会不会伤车？喵哥一次给你讲清楚
- 27岁，转行java的血与泪，该何去何从
- 怎样统计工程中未使用的java类
- 新互联网网站用Java还靠谱么对比Php，Python，Ruby的话
- 我想学java和安卓软件开发?
- 学计算机专业，java那些和网站开发选台式还是笔记本好
- JAVA设计思路