乐观锁和悲观锁能够解决什么问题？
并发场景下，有序地更新某条记录。
什么是乐观锁，什么是悲观锁？
乐观锁：乐观锁在操作数据时非常乐观，认为别人不会同时修改数据。
因此乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃操作，否则执行操作。
悲观锁：悲观锁在操作数据时比较悲观，认为别人会同时修改数据。
因此操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据。
两种锁的应该如何实现？
乐观锁的实现方式主要有两种：CAS机制和版本号机制
CAS：（Compare And Swap）
CAS操作包括了3个操作数：
1) 需要读写的内存位置(V)
2) 进行比较的预期值(A)
3) 拟写入的新值(B)
复制代码操作逻辑如下：
如果内存位置V的值等于预期的A值，则将该位置更新为新值B，否则不进行任何操作。
许多CAS的操作是自旋的：如果操作不成功，会一直重试，直到操作成功为止。
这里引出一个新的问题，既然CAS包含了Compare和Swap两个操作，它又如何保证原子性呢？
答案是：CAS是由CPU支持的原子操作，其原子性是在硬件层面进行保证的。
注意：Java中的自增操作
(i++)在并发场景下就不能百分百得到准确的结果，因为它并不是原子操作。在并发场景下应该使用
AtomicInteger进行自增操作，其内部也是靠CAS乐观锁实现的顺序自增。
版本号机制（Version）
版本号机制的基本思路是在数据中增加一个字段version，表示该数据的版本号，每当数据被修改，版本号加1。
- 当某个线程查询数据时，将该数据的版本号一起查出来；
- 当该线程更新数据时，判断当前版本号与之前读取的版本号是否一致，如果一致才进行操作。
需要注意的是，这里使用了版本号作为判断数据变化的标记，实际上可以根据实际情况选用其他能够标记数据版本的字段，如时间戳等。
悲观锁的两种实现：synchronized和select...for update 代码实现悲观锁：synchronized synchronized通过对代码块加锁来保证线程安全：在同一时刻，只能有一个线程可以执行代码块中的代码。
synchronized是一个重量级的操作，不仅是因为加锁需要消耗额外的资源，还因为线程状态的切换会涉及操作系统核心态和用户态的转换；
不过随着JVM对锁进行的一系列优化(如自旋锁、轻量级锁、锁粗化等)，synchronized的性能表现已经越来越好。
sql实现悲观锁select...for update
该查询语句会为该行记录加上排它锁，直到事务提交或回滚时才会释放排它锁；
在此期间，如果其他事务只能对该行记录执行查询操作，如果更新该行记录信息或者执行select for update，会被阻塞。
ps：用select for update一定要跟上where id = ? 的条件，id字段一定是主键或者唯一索引，不然会导致锁全表，后果很严重！
分析一下两种锁的优劣势？
乐观锁
优势：
- 轻量级锁，避免了线程切换的开销。
劣势：
- 会有ABA问题
假设有两个线程——线程1和线程2，两个线程按照顺序进行以下操作
(1)线程1读取内存中数据为A；
(2)线程2将该数据修改为B；
(3)线程2将该数据修改为A；
(4)线程1对数据进行CAS操作
在第(4)步中，由于内存中数据仍然为A，因此CAS操作成功，但实际上该数据已经被线程2修改过了。这就是ABA问题。
-
只能对单一变量加锁
-
自旋操作导致额外开销
悲观锁
优势：
- 因为锁的是代码块，可以锁住多个变量。
劣势：
- 重量级锁，加锁、释放锁操作会有开销，而且操作系统层面的上下文切换和线程调度也会引起很大的开销。
- 一个线程持有锁会导致其它所有需要此锁的线程挂起。
不同场景如何选型乐观锁和悲观锁？
高并发高竞争下，为了避免重试开销，直接选用悲观锁。
比如火车票订票，在屏幕上显示有票，而真正进行出票时，需要重新确定一下这个数据没有被其他客户端修改。所以，在这个确认过程中，可以使用for update。
并发情况不激烈，偶尔解决并发问题，选择性能消耗小的乐观锁。