锁策略, cas 和 synchronized 优化过程
常见的锁策略
1）乐观锁与悲观锁：这里的锁并不是指某个具体的锁，而是概念，描述锁的特性，描述的是一类锁。
乐观锁：预测该场景中，不太容易出现锁冲突的情况。后续做的工作较少。
悲观锁：预测该场景中，非常容易出现锁冲突的情况。后续做的工作较多。
2）重量级锁和轻量级锁：
重量级锁：加锁的开销比较大（花的时间多，占用系统资源多），一个悲观锁（后续做的工作较多）很可能就是一个重量级锁。
轻量级锁：加锁的开销比较小（花的时间少，占用系统资源少），一个乐观锁（后续做的工作较少）很可能就是一个轻量级锁。
悲观乐观，是在加锁之前，对锁冲突概率的预测。
轻量重量，是在加锁之后，考量实际的锁的开销。
3）自旋锁和挂起等待锁：
自旋锁是轻量级锁的一种典型实现，在用户态下，通过自旋的方式（如while（）），实现类似与锁的机制。如果发生阻塞时，线程会一直循环尝试访问，使之能最快速度能获取到这把锁。因为是第一时间发现，因此花费的时间更少，但是因为一直尝试获取，所占用的资源更多。
挂起等待锁是重量级锁的一种典型实现，通过内核态，借助系统提供的锁机制，当出现锁冲突时，会牵扯到内核对与线程的调度，使冲突的线程出现阻塞等待。线程会不再访问，直到发现该锁被释放后，才去尝试获取这把锁，因为不是第一时间发现，可能途中这把锁已经被多次释放，因此花费的时间更多，但是因为不需要一直尝试获取，所占用的资源更少。
4）读写锁与互斥锁：
读写锁：把读操作加锁和写操作加锁给分开了，多个线程同时取读同一个变量，不涉及到线程安全问题。如果两个线程都是读加锁的话，不产生锁竞争，一个线程读加锁，一个线程写加锁，会产生锁竞争，两个线程都是写加锁的话，会产生锁竞争。与数据库事务的锁类似，但事务的锁更为细致，情况更多。
互斥锁：就是普通的锁，一个线程获取了这把锁后，其他的线程就不能获取，直到它被释放。
5）公平锁和非公平锁：
公平锁：遵守先来后到的规则，多个线程等待一把锁的释放，其中一个线程最先来的，那么它就能比其他的线程更快的获取这把锁。
非公平锁：不遵守先来后到的规则，多个线程等待一把锁的释放，它们获取这把锁的概率是相同的。操作系统自带的锁（pthread_mutex）就是非公平锁。
6）可重入锁与不可重入锁：如果一个线程针对一把锁，连续加锁两次，如果出现死锁的话，就是不可重入锁，不出现死锁的话，则是可重入锁。
synchronized 具体采用了哪些锁策略呢？
1.synchronized既是悲观锁，又是乐观锁。（在某些情况下是悲观锁，在某些情况下又是乐观锁）
2.synchronized即使重量级锁，又是轻量级锁。synchronized重量级锁部分是基于系统的互斥锁实现的，轻量级锁部分是基于自旋锁实现的
3.synchronized是非公平锁
4.synchronized是可重入锁。
5.synchronized不是读写锁。
synchronized内部实现策略（内部原理）：代码写了一个synchronized之后，这里可能会产生一系列的”自适应的过程“，这个过程也称为锁升级或锁膨胀，synchronized就会从无锁状态到偏向锁（偏向锁，不是真的加锁，而是只做了标记，如果有别的线程来竞争锁，才会真的加锁，否则就自始至终都不加锁），当有其他线程来竞争锁后就升级为轻量级锁，当竞争变得更激烈后就升级为重量级锁。
锁消除：编译器会智能的判定，该代码是否需要加锁，如果加了锁，但其实实际上没必要加锁，那么就会把加锁操作自动消除。
锁粗化：与锁的粒度有关，如果加锁操作里面的包含的实际要执行的操作越多，就认为锁的粒度越大，有些时候希望锁的粒度大，因为加锁也需要开销，有时希望锁的粒度小，并发程度高。当一段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会自动进行锁的粗化.
关于cas
cas，全称为compare and swap，就是字面意义的比较和交换。能够比较和交换某个寄存器中的值和内存中的值，看看是否相等，如果相等，则把另外一个寄存器中的值进行交换。
cas伪代码：
public static AtomicInteger atomicInteger = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread thread = new Thread(() -> {
for (int i = 0; i < 10000; i++) {
atomicInteger.getAndIncrement();//相当于count++
// atomicInteger.incrementAndGet();//相当于++count
// atomicInteger.decrementAndGet();//相当于--count
// atomicInteger.getAndDecrement();//相当于count--；
}
});
Thread thread1 = new Thread(() -> {
for (int i = 0; i < 10000; i++) {
atomicInteger.getAndIncrement();
}
});
thread.start();
thread1.start();
thread.join();
thread1.join();
System.out.println(atomicInteger.get());
}
并没有加锁，就完成了代码的正确运行。那么它是如何做到的呢？以下是伪代码实现：
CAS的ABA问题：
解决CAS问题：
那么如何解决这个问题呢？我们可以给要修改的数据引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期.如果发现当前版本号和之前读到的版本号一致, 就真正执行修改操作, 并让版本号自增; 如果发现当前版本号比之前读到的版本号大, 就认为操作失败。