乐观锁和悲观锁
悲观锁：读、写都加锁。默认每个资源都有很多线程争抢，获得了资源就先加上锁再操作，但是加锁和释放成本高。
乐观锁：读不加锁，写加锁。

cas
compare and swap
默认没有线程和自己争抢资源，先记下操作前的快照，操作完后来对比下资源是否被修改过，如果没人来过，就写入新值，否则重新执行刚才的操作。
这里存在aba的问题，即“虽然还是刚才存起来的值，但这段时间里，有人改过两次又改回原值”，这时就会有错误。
根据版本号判断可以解决这个问题。

java对象头
对象头包含markword、类型指针、数组长度三部分。
markword有：指向栈中锁记录的指针、偏向线程id、锁状态等信息。
通过markword内容，可以看出对象处于无锁还是偏向锁、轻量级锁、重量级锁。
多线程下synchronized的加锁就是对同一个对象头中markword中的变量进行cas操作。

偏向锁
很多时候一个加了锁的代码块自始至终都只有一个线程访问，此时用偏向锁，可以节省加锁解锁的开销。
当这个线程持有锁之后，只要没有线程来竞争这个锁，他将一直持有锁，每次执行加锁代码块块前后，只要看看markword里记录的“持有偏向锁的线程”是不是自己就行。
当发生竞争时，偏向锁会升级变成轻量级锁。

轻量级锁
线程a和b竞争对象的锁。
1.抢锁就是cas的改markword，谁改成功了，谁就抢到了。（把无锁的markword改成指向自己栈中锁记录的指针，旧的markword记在自己的栈帧里）
2.没有抢到锁的线程，自旋（重试）等着抢到锁的线程释放锁。所以轻量级锁适用于锁粒度小，很快就释放了场景，可以省下加锁解锁的开销。锁粒度太大的话，自旋很占cpu资源，不如用重量级锁。
3.如果自旋n次结束之后资源还是没有释放，轻量级锁就膨胀成重量级锁，这个线程挂起，接下来想竞争这个资源的线程，直接挂起。

10重量级锁

synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的，监视器锁本身依赖底层的操作系统的 Mutex Lock来实现。操作系统实现线程的切换需要从用户态切换到核心态，成本非常高。这种依赖于操作系统 Mutex Lock来实现的锁称为重量级锁。为了优化synchonized，引入了轻量级锁，偏向锁。