应用场景
悲观锁
主要是强一致性要求
比如金融，银行，支付，钱的方面
基本上都是悲观锁
乐观锁
主要是性能要求超过强一致性要求
比如电商商品的库存
还有电商商品的商品信息
说白了，就是读多写少
比如电商商品，大部分人只看不买，就像逛街一样，这个时候，大部分人只读商品信息
库存也一样，看多买少
另外，社交网站内容，比如微博
社区网站内容，比如技术社区的文章啥的
都是读多写少
所以比较适合乐观锁
说白了，就是极端情况下，哪怕个别数据异常，也不至于亏钱，就这么简单，这个技术都是应用场景决定的
实现
悲观锁
数据库：基于select for update
Java代码：基于Redis分布式
两种不同的解决方案，要解决的问题是一样的
思想也是有的
只不过是基于不同的技术方案去解决而已
说白了，就是基于Redis分布式锁，优点是性能比关系数据库更高一点，缺点是引入了新的中间件
乐观锁
数据库：基于版本号字段
Java代码：基于CAS
也是一样，要解决的问题是一样的
只不过是不同的技术方案
乐观锁，能100%确保数据强一致性吗？
能是能
但是和悲观锁，还有一个很大的实际应用的区别
就是乐观锁，只确保单个更新操作的100%，多个更新操作，就确保不了
只能使用悲观锁
工作实战
所以，即便乐观锁，能解决单个更新操作的线程安全问题
但是，在项目当中，一般都是用悲观锁
因为强一致性肯定大于高性能，特别是金融应用场景
另外，大部分系统，也没有那么高的性能要求
而且，即便是有，也是单笔数据库数据的加锁，而不是锁整个表
说白了就是，即便是有很高的交易量，比如支付系统，那是整个系统的交易量很大，但是呢，单笔订单的并发量其实是很小的
所以这个时候，用悲观锁就够了，没有必要用乐观锁，而且支付系统都会包含多个更新操作，乐观锁也不满足要求
