Java 锁
乐观锁
乐观锁是一种乐观思想，认为读多写少，遇到并发的可能低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下此期间别人是否更新过这个数据，采取在写的时候先读取当时的版本号然后加锁锁操作， 如果失败则要重复读-比较-写的操作。
悲观锁
悲观锁就是悲观思想，认为写多，遇到并发写的可能性比较高，每次去拿数据的时候都认为别人会修改，所以在读写数据的时候都会上锁，这样别人想读写这个数据的似乎就会block直到拿到锁。 Java中的悲观锁就是Synchronized，AQS框架下的锁是先尝试cas乐观锁去获取锁，获取不到，才会转换为悲观锁，如RetreenLock（可重入锁）。
自旋锁
如果持有锁的线程能在很短时间内释放锁资源，那么等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，他们只需要等一等（自旋），等待有锁的线程释放锁后即可立即获得锁，这样就避免用户线程和内核的切换消耗。
线程自旋是需要消耗cpu的，就是让cpu在做无用功，如果一直获取不到锁，那线程也不能一直占用cpu自旋做无用功，所以需要设定一个自旋等待的最大时间。
如果持有锁的线程执行时间超过自旋等待的最大时间仍然没有释放锁，就会导致其他争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程就会停止自旋进入阻塞状态。
自旋锁的优缺点：
自旋锁尽可能减少线程的阻塞，对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度提升，因为自旋的消耗会小于线程阻塞挂起再唤醒的操作消耗，这些操作会导致线程发生两次上下文切换。 如果锁的竞争记录，或者持有锁线程需要长时间占用锁执行同步块，这时候就不适合使用自旋，因为自旋获取锁一直都再占用cpu做无用功，同时有大量的线程在竞争一个锁，会导致获取锁的时间很长， 线程自旋的消耗大于线程阻塞挂起操作的消耗，其他需要cpu的线程又不能获取，造成资源浪费，这种情况下要关闭自旋锁。
自旋锁的时间阈值（JDK1.6引入了适应性自旋锁）
自旋锁的目的是为了占着CPU资源不释放，等获取到锁立即处理，如何去选择自旋时间呢？如果自旋执行时间太长，会有大量的线程处于自旋状态占用cpu资源，影响整体系统的性能，因此自旋周期格外重要。 JVM对于自旋周期的选择，JDK1.5这个限度时写死的，在1.6引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不是固定的，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定， 基本认为一个线程上下文切换的时间时最佳的一个时间，同时JVM还针对当前CPU的负荷情况做了较多的优化，如果平均负载小于CPUs则一直自旋，如果超过（CPUs/2）个线程正在自旋，则后来线程直接阻塞， 如果正在自旋的线程发现Owner发生了变化则延迟自旋时间（自旋计数）或进入阻塞，如果CPU处于节电模式则停止自旋，自旋时间最坏情况时CPU的存储延迟，自旋时会适当放弃线程优先级之间的差异。
自旋锁的开启
JDK1.6中 -XX：+ UseSprinning开启； -XX：PreBlockSpin=10 为自旋次数； JDK1.7后，去除此参数，由JVM控制；
同步锁 （Synchronized）
Synchronized可以把任意一个非Null的对象当作锁，属于独占式的悲观锁，同时属于可重入锁。
- Synchronized作用范围
- 作用方法时，锁住的对象的实例（this）
- 当作用于静态方法时，锁住的是Class实例，又因为Class的相关数据存储在永久代PermGen（JDK1.8是metaspace），永久代是全局共享的，因此静态方法锁相当于类的一个全局锁， 会锁所有调用该方法的线程。
- synchronized作用于对象实例时，所著的时所有以该对象为锁的代码块，它又多个队列，当多个线程一起访问某个对象监视器的时候，对象监视器会将这些线程存储在不同容器中。
- Synchronized核心组件
1) Wait Set：哪些调用 wait 方法被阻塞的线程被放置在这里； 2) Contention List：竞争队列，所有请求锁的线程首先被放在这个竞争队列中； 3) Entry List：Contention List 中那些有资格成为候选资源的线程被移动到 Entry List 中； 4) OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为 OnDeck； 5) Owner：当前已经获取到所资源的线程被称为 Owner； 6) !Owner：当前释放锁的线程。
- Synchronized 实现
-
JVM 每次从队列的尾部取出一个数据用于锁竞争候选者（OnDeck），但是并发情况下，ContentionList 会被大量的并发线程进行 CAS 访问，为了降低对尾部元素的竞争，JVM 会将一部分线程移动到 EntryList 中作为候选竞争线程。
-
Owner 线程会在 unlock 时，将 ContentionList 中的部分线程迁移到 EntryList 中，并指定EntryList 中的某个线程为 OnDeck 线程（一般是最先进去的那个线程）。
-
Owner 线程并不直接把锁传递给 OnDeck 线程，而是把锁竞争的权利交给 OnDeck，OnDeck 需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大的提升系统的吞吐量，在JVM 中，也把这种选择行为称之为“竞争切换”。
-
OnDeck 线程获取到锁资源后会变为 Owner 线程，而没有得到锁资源的仍然停留在 EntryList中。如果 Owner 线程被 wait 方法阻塞，则转移到 WaitSet 队列中，直到某个时刻通过 notify或者 notifyAll 唤醒，会重新进去 EntryList 中。
-
处于 ContentionList、EntryList、WaitSet 中的线程都处于阻塞状态，该阻塞是由操作系统来完成的（Linux 内核下采用 pthread_mutex_lock 内核函数实现的）。
-
Synchronized 是非公平锁。 Synchronized 在线程进入 ContentionList 时，等待的线程会先尝试自旋获取锁，如果获取不到就进入 ContentionList，这明显对于已经进入队列的线程是不公平的，还有一个不公平的事情就是自旋获取锁的线程还可能直接抢占 OnDeck 线程的锁资源。
-
每个对象都有个 monitor 对象，加锁就是在竞争 monitor 对象，代码块加锁是在前后分别加上 monitorenter 和 monitorexit 指令来实现的，方法加锁是通过一个标记位来判断的
-
synchronized 是一个重量级操作，需要调用操作系统相关接口，性能是低效的，有可能给线程加锁消耗的时间比有用操作消耗的时间更多。
-
Java1.6，synchronized 进行了很多的优化，有适应自旋、锁消除、锁粗化、轻量级锁及偏向锁等，效率有了本质上的提高。在之后推出的 Java1.7 与 1.8 中，均对该关键字的实现机理做了优化。引入了偏向锁和轻量级锁。都是在对象头中有标记位，不需要经过操作系统加锁。
-
锁可以从偏向锁升级到轻量级锁，再升级到重量级锁。这种升级过程叫做锁膨胀；
-
JDK 1.6 中默认是开启偏向锁和轻量级锁，可以通过-XX:-UseBiasedLocking 来禁用偏向锁。
- ReentrantLock
ReentrantLock 继承了Lock实现接口定义的方法，是一种可重入锁，除了能完成synchronized所能完成的工作外，还提供了可响应中断锁，可轮询锁请求，定时锁等避免多线程死锁的方法。
Lock接口的主要方法：
-
void lock();执行方法时，如果锁处于空闲状态，当前线程将获取到锁，相反，如果锁已经被其他线程持有，将禁用当前线程，直到当前线程获取到锁。
-
boolean tryLock();如果锁可用，则获取锁，并立即返回true，否则返回false，该方法和lock()的区别再有，tryLock()只是试图获取锁，如果锁不可用，不会导致当前线程被禁用，当前线程仍然继续向下执行。 而lock()方法则一定要获取到锁，如果锁不可用，就一直等待，再未获取到锁之前，当前线程并不继续向下执行。
-
void unlock(); 执行此方法时，当前线程将释放持有的锁，锁只能由持有者释放，如果线程并不持有锁，却执行该方法，可能导致异常发生。
-
Condition NewCondition() 条件对象，获取等待通知组件，该组件和当前锁绑定，当前线程只有获取了锁，才能调用该组件的await()方法，而调用后，当前线程将缩放锁。
-
getHoldCount();查询当前线程保持此锁的次数，也是执行此线程执行lock方法的次数。
-
getQueueLength();返回正等待获取此锁的线程估计数，比如启动10个线程，1个线程获得此锁，返回值为9。
-
getWaitQueueLength(Condition);返回等待与此锁相关的给定条件的线程计数，比如启动10个线程，用同一个condition对象，并且此时10个线程都执行了condition对象的await方法，那么此时执行方法返回10.
-
hasWaiters(Condition); 查询释放有线程等待与此锁相关的给定条件condition，对于指定condition对象，有多少线程执行了condition.await方法。
-
hasQueuedThread(Thread thread) 查询给定线程是否等待获取此锁。
-
hasQueuedThreads();是否有线程等待此锁。
-
isFair();是否公平锁。
-
isHeldByCurrentThread();当前线程是否保持锁锁定，线程得执行lock方法得前后分别是false和true。
-
isLock();此锁是否有任意线程占用。
-
lockInterruptibly(); 如果当前线程未被中断，获取锁。
-
tryLock();尝试获得锁，仅在调用锁未被线程占用，获得锁。
-
tryLock(long timeout TimeUnit unit)：如果锁在给定等待时间内没有被另一个线程保持，则获取该锁。
- Semaphore 与 ReentrantLock
Semaphore 基本能完成 ReentrantLock 的所有工作，使用方法也与之类似，通过 acquire()与release()方法来获得和释放临界资源。 经实测，Semaphone.acquire()方法默认为可响应中断锁，与 ReentrantLock.lockInterruptibly()作用效果一致，也就是说在等待临界资源的过程中可以被Thread.interrupt()方法中断。 此外，Semaphore 也实现了可轮询的锁请求与定时锁的功能，除了方法名 tryAcquire 与 tryLock不同，其使用方法与 ReentrantLock 几乎一致。Semaphore 也提供了公平与非公平锁的机制，也可在构造函数中进行设定。 Semaphore 的锁释放操作也由手动进行，因此与 ReentrantLock 一样，为避免线程因抛出异常而无法正常释放锁的情况发生，释放锁的操作也必须在 finally 代码块中完成。
- AtomicInteger
首先说明，此处 AtomicInteger ，一个提供原子操作的 Integer 的类，常见的还有AtomicBoolean、AtomicInteger、AtomicLong、AtomicReference 等，他们的实现原理相同，区别在与运算对象类型的不同。
令人兴奋地，还可以通过 AtomicReference
- 可重入锁（递归锁）
本文里面讲的是广义上的可重入锁，而不是单指 JAVA 下的 ReentrantLock。可重入锁，也叫做递归锁，指的是同一线程 外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。在 JAVA 环境下 ReentrantLock 和 synchronized 都是 可重入锁。
- ReadWriteLock 读写锁
为了提高性能，Java 提供了读写锁，在读的地方使用读锁，在写的地方使用写锁，灵活控制，如果没有写锁的情况下，读是无阻塞的,在一定程度上提高了程序的执行效率。 读写锁分为读锁和写锁，多个读锁不互斥，读锁与写锁互斥，这是由 jvm 自己控制的，你只要上好相应的锁即可。
读锁
如果你的代码只读数据，可以很多人同时读，但不能同时写，那就上读锁。
写锁 如果你的代码修改数据，只能有一个人在写，且不能同时读取，那就上写锁。总之，读的时候上读锁，写的时候上写锁！ Java中读写锁有个接口java.util.concurrent.locks.ReadWriteLock，也有具体的实现ReentrantReadWriteLock。
- 共享锁和独占锁
java 并发包提供的加锁模式分为独占锁和共享锁。
独占锁
独占锁模式下，每次只能有一个线程能持有锁，ReentrantLock 就是以独占方式实现的互斥锁。
独占锁是一种悲观保守的加锁策略，它避免了读/读冲突，如果某个只读线程获取锁，则其他读线程都只能等待，这种情况下就限制了不必要的并发性，因为读操作并不会影响数据的一致性。
共享锁
共享锁则允许多个线程同时获取锁，并发访问 共享资源，如：ReadWriteLock。共享锁则是一种乐观锁，它放宽了加锁策略，允许多个执行读操作的线程同时访问共享资源。
- AQS 的内部类 Node 定义了两个常量 SHARED 和 EXCLUSIVE，他们分别标识 AQS 队列中等待线程的锁获取模式。
- java 的并发包中提供了 ReadWriteLock，读-写锁。它允许一个资源可以被多个读操作访问，或者被一个 写操作访问，但两者不能同时进行。
- 重量级锁（Mutex Lock）
Synchronized 是通过对象内部的一个叫做监视器锁（monitor）来实现的。但是监视器锁本质又是依赖于底层的操作系统的 Mutex Lock 来实现的。 而操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized 效率低的原因。 因此，这种依赖于操作系统 Mutex Lock 所实现的锁我们称之为“重量级锁”。JDK 中对 Synchronized 做的种种优化，其核心都是为了减少这种重量级锁的使用。 JDK1.6 以后，为了减少获得锁和释放锁所带来的性能消耗，提高性能，引入了“轻量级锁”和“偏向锁”。
- 轻量级锁
锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。
锁升级
随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。 “轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的。但是，首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的， 它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用产生的性能消耗。在解释轻量级锁的执行过程之前，先明白一点， 轻量级锁所适应的场景是线程交替执行同步块的情况，如果存在同一时间访问同一锁的情况，就会导致轻量级锁膨胀为重量级锁。
- 偏向锁
Hotspot 的作者经过以往的研究发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得。偏向锁的目的是在某个线程获得锁之后， 消除这个线程锁重入（CAS）的开销，看起来让这个线程得到了偏护。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径， 因为轻量级锁的获取及释放依赖多次 CAS 原子指令，而偏向锁只需要在置换ThreadID 的时候依赖一次 CAS 原子指令 （由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的 CAS 原子指令的性能消耗）。 上面说过，轻量级锁是为了在线程交替执行同步块时提高性能，而偏向锁则是在只有一个线程执行同步块时进一步提高性能。
锁优化
减少锁持有时间
只用在有线程安全要求的程序上加锁，减小锁粒度，将大对象（这个对象可能会被很多线程访问），拆成小对象，大大增加并行度，降低锁竞争。 降低了锁的竞争，偏向锁，轻量级锁成功率才会提高。最最典型的减小锁粒度的案例就是ConcurrentHashMap。
锁分离
最常见的锁分离就是读写锁 ReadWriteLock，根据功能进行分离成读锁和写锁，这样读读不互斥，读写互斥，写写互斥，即保证了线程安全，又提高了性能。 JDK 并发包 1。读写分离思想可以延伸，只要操作互不影响，锁就可以分离。比如LinkedBlockingQueue 从头部取出，从尾部放数据
锁粗化
通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽量短，即在使用完公共资源后，应该立即释放锁。但是，凡事都有一个度， 如果对同一个锁不停的进行请求、同步和释放，其本身也会消耗系统宝贵的资源，反而不利于性能的优化 。
锁消除
锁消除是在编译器级别的事情。在即时编译器时，如果发现不可能被共享的对象，则可以消除这些对象的锁操作，多数是因为程序员编码不规范引起。