知识点总结
java 类加载的过程 ？ 双亲委派模式
https://blog.csdn.net/ren365880/article/details/83786535
Java 虚拟机一般使用 Java 类的流程为：
首先将开发者编写的 Java 源代码（.java文件）编译成 Java 字节码（.class文件），
然后类加载器会读取这个 .class 文件，并转换成 java.lang.Class 的实例。
有了该 Class 实例后，Java 虚拟机可以利用 newInstance 之类的方法创建其真正对象了。
ClassLoader 是 Java 提供的类加载器，绝大多数的类加载器都继承自 ClassLoader，它们被用来加载不同来源的 Class 文件。
类从被加载到JVM中开始，到卸载为止，整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。
其中类加载过程包括加载、验证、准备、解析和初始化五个阶段。验证、准备和解析这三个部分统称为连接（linking）。
加载
简单的说，类加载阶段就是由类加载器负责根据一个类的全限定名来读取此类的二进制字节流到JVM内部，并存储在运行时内存区的方法区，然后将其转换为一个与目标类型对应的java.lang.Class对象实例（Java虚拟机规范并没有明确要求一定要存储在堆区中，只是hotspot选择将Class对戏那个存储在方法区中），这个Class对象在日后就会作为方法区中该类的各种数据的访问入口。
链接
链接阶段要做的是将加载到JVM中的二进制字节流的类数据信息合并到JVM的运行时状态中，经由验证、准备和解析三个阶段。
1验证
验证类数据信息是否符合JVM规范，是否是一个有效的字节码文件，验证内容涵盖了类数据信息的格式验证、语义分析、操作验证等。
格式验证：验证是否符合class文件规范
语义验证：检查一个被标记为final的类型是否包含子类；检查一个类中的final方法视频被子类进行重写；确保父类和子类之间没有不兼容的一些方法声明（比如方法签名相同，但方法的返回值不同）
操作验证：在操作数栈中的数据必须进行正确的操作，对常量池中的各种符号引用执行验证（通常在解析阶段执行，检查是否通过富豪引用中描述的全限定名定位到指定类型上，以及类成员信息的访问修饰符是否允许访问等）
2准备
为类中的所有静态变量分配内存空间，并为其设置一个初始值（由于还没有产生对象，实例变量不在此操作范围内）
被final修饰的静态变量，会直接赋予原值；类字段的字段属性表中存在ConstantValue属性，则在准备阶段，其值就是ConstantValue的值
3解析
将常量池中的符号引用转为直接引用（得到类或者字段、方法在内存中的指针或者偏移量，以便直接调用该方法），这个可以在初始化之后再执行。
可以认为是一些静态绑定的会被解析，动态绑定则只会在运行是进行解析；静态绑定包括一些final方法(不可以重写),static方法(只会属于当前类)，构造器(不会被重写)
初始化
将一个类中所有被static关键字标识的代码统一执行一遍，如果执行的是静态变量，那么就会使用用户指定的值覆盖之前在准备阶段设置的初始值；如果执行的是static代码块，那么在初始化阶段，JVM就会执行static代码块中定义的所有操作。
哪些 ClassLoader 负责加载上面几类 Class？
实际上，针对上面四种来源的类，分别有不同的加载器负责加载。
首先，我们来看级别最高的 Java 核心类，即$JAVA_HOME/jre/lib 里的核心 jar 文件。这些类是 Java 运行的基础类，由一个名为 BootstrapClassLoader 加载器负责加载，它也被称作 根加载器／引导加载器。注意，BootstrapClassLoader 比较特殊，它不继承 ClassLoader，而是由 JVM 内部实现；
然后，需要加载 Java 核心扩展类，即 $JAVA_HOME/jre/lib/ext 目录下的 jar 文件。这些文件由 ExtensionClassLoader 负责加载，它也被称作 扩展类加载器。当然，用户如果把自己开发的 jar 文件放在这个目录，也会被 ExtClassLoader 加载；
接下来是开发者在项目中编写的类，这些文件将由 AppClassLoader 加载器进行加载，它也被称作 系统类加载器 System ClassLoader；
最后，如果想远程加载如（本地文件／网络下载）的方式，则必须要自己自定义一个 ClassLoader，复写其中的 findClass() 方法才能得以实现。
因此能看出，Java 里提供了至少四类 ClassLoader 来分别加载不同来源的 Class。
不同加载器是如何工作的？什么是双亲委托模型及双亲委托存在的意义。
String 类是 Java 自带的最常用的一个类，现在的问题是，JVM 将以何种方式把 String class 加载进来呢？
我们来猜想下。
首先，String 类属于 Java 核心类，位于 $JAVA_HOME/jre/lib 目录下。有的朋友会马上反应过来，上文中提过了，该目录下的类会由 BootstrapClassLoader 进行加载。没错，它确实是由 BootstrapClassLoader 进行加载。但，这种回答的前提是你已经知道了 String 在 $JAVA_HOME/jre/lib 目录下。
那么，如果你并不知道 String 类究竟位于哪呢？或者我希望你去加载一个 unknown 的类呢？
有的朋友这时会说，那很简单，只要去遍历一遍所有的类，看看这个 unknown 的类位于哪里，然后再用对应的加载器去加载。
是的，思路很正确。那应该如何去遍历呢？
比如，可以先遍历用户自己写的类，如果找到了就用 AppClassLoader 去加载；否则去遍历 Java 核心类目录，找到了就用 BootstrapClassLoader 去加载，否则就去遍历 Java 扩展类库，依次类推。
这种思路方向是正确的，不过存在一个漏洞。
假如开发者自己伪造了一个 java.lang.String 类，即在项目中创建一个包java.lang，包内创建一个名为 String 的类，这完全可以做到。那如果利用上面的遍历方法，是不是这个项目中用到的 String 不是都变成了这个伪造的 java.lang.String 类吗？如何解决这个问题呢？
当一个类加载器接收到一个类加载的任务时，不会立即展开加载，而是将加载任务委托给它的父类加载器去执行，每一层的类都采用相同的方式，直至委托给最顶层的启动类加载器为止。如果父类加载器无法加载委托给它的类，便将类的加载任务退回给下一级类加载器去执行加载。
双亲委托模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委托给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需要加载的类）时，子加载器才会尝试自己去加载。
使用双亲委托机制的好处是：能够有效确保一个类的全局唯一性，当程序中出现多个限定名相同的类时，类加载器在执行加载时，始终只会加载其中的某一个类。
使用双亲委托模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委托给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种加载器环境中都是同一个类。相反，如果没有使用双亲委托模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。如果自己去编写一个与rt.jar类库中已有类重名的Java类，将会发现可以正常编译，但永远无法被加载运行。
双亲委托模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲委托的代码都集中在java.lang.ClassLoader的loadClass()方法中，逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父类加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载器加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass方法进行加载。
类加载器的应用：自定义类加载器
自定义类加载器，它允许我们在运行时可以从本地磁盘或网络上动态加载自定义类。这使得开发者可以动态修复某些有问题的类，热更新代码。
自定义类加载器需要继承抽象类ClassLoader，实现findClass方法，该方法会在loadClass调用的时候被调用，findClass默认会抛出异常。不是loadClass()方法，因为ClassLoader提供了loadClass()（如上面的源码），它会基于双亲委托机制去搜索某个 class，直到搜索不到才会调用自身的findClass()，如果直接复写loadClass()，那还要实现双亲委托机制
findClass方法表示根据类名查找类对象
loadClass方法表示根据类名进行双亲委托模型进行类加载并返回类对象
defineClass方法表示跟根据类的字节码转换为类对象
NoClassDefError ClassNotFoundEException 区别
Error与Exception：
Error仅在java的虚拟机中发生，用户无需在程序中捕捉或者抛出Error。
Exception分为一般的Exception和RuntimeException两类，其中，RuntimeException为Unchecked型，而Exception为Checked型。
checked与unchecked
checked： 一般是指程序不能直接控制的外界情况，是指在编译的时候就需要检查的一类exception，用户程序中必须采用try-catch机制处理或者通过throws交由调用者来处理。这类异常，主要指除了Error以及RuntimeException及其子类之外的异常。
unchecked：是指那些不需要在编译的时候就要处理的一类异常。在java体系里，所有的Error以及RuntimeException及其子类都是unchecked异常。可直白的理解为：不需要try-catch等机制处理的异常，可以认为是unchecked的异常。
ClassNotFoundException为非RuntimeException(CheckedException)，也就是说该异常在程序编译前就会检查出该错误，导致无法通过编译，逼迫程序员修改代码。所以这里的ClassNotFoundException应该指的是找不到所定义的Class的代码段。
2）NoClassDefError并不是发生在编译前，而是编译后的运行期间(通常在jvm类加载过程)，通常分以下三种成因：
①加载该类时发现找不到该类的.class文件或者该类的jar包不存在；
②类的.class文件存在，但是在不同的域中。比如说，.class在当前的java path下不可用又或者说有多个不同的类加载器重复对该类的.class文件进行了加载，就有可能出现这样的问题；
③大小写问题，因为在编译时，虽然类名可能大小写不同，但如果字母都一样，那么最后不管类名大小写是否相同，编译后都只产生一个.class文件！这样就会导致最后编译出来的文件不是我们想要的。
强引用、软引用、弱引用、虚引用
强引用
Object obj = new Object(); //只要obj还指向Object对象，Object对象就不会被回收 obj = null; //手动置null
只要强引用存在，垃圾回收器将永远不会回收被引用的对象，哪怕内存不足时，JVM也会直接抛出OutOfMemoryError，不会去回收。如果想中断强引用与对象之间的联系，可以显示的将强引用赋值为null，这样一来，JVM就可以适时的回收对象了
Object obj = new Object();
软引用
软引用是用来描述一些非必需但仍有用的对象。在内存足够的时候，软引用对象不会被回收，只有在内存不足时，系统则会回收软引用对象，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常。这种特性常常被用来实现缓存技术，比如网页缓存，图片缓存等。
在 JDK1.2 之后，用java.lang.ref.SoftReference类来表示软引用
SoftReference
弱引用
弱引用的引用强度比软引用要更弱一些，无论内存是否足够，只要 JVM 开始进行垃圾回收，那些被弱引用关联的对象都会被回收。在 JDK1.2 之后，用 java.lang.ref.WeakReference 来表示弱引用。
Obejct oj = new Object();
WeakReference
oj = null; System.gc(); //下面会发现有时候直接返回null;wf.get();
虚引用
虚引用是最弱的一种引用关系，如果一个对象仅持有虚引用，那么它就和没有任何引用一样，它随时可能会被回收，在 JDK1.2 之后，用 PhantomReference 类来表示，通过查看这个类的源码，发现它只有一个构造函数和一个 get() 方法，而且它的 get() 方法仅仅是返回一个null，也就是说将永远无法通过虚引用来获取对象，虚引用必须要和 ReferenceQueue 引用队列一起使用。
// 虚引用
Object oj= new Object();
ReferenceQueue req= new ReferenceQueue();
PhantomReference
StringBuffer StringBuilder
StringBuffer与StringBuilder的共同之处
1、都继成了AbstractStringBuilder这个抽象类，实现了CharSequence接口
2、其append方法都是 super.append(str)，调用了父类AbstractStringBuilder的append(String str)方法
3、初始容量都是16和扩容机制都是”旧容量*2+2”
4、底层都是用char[]字符数组实现，且字符数组都是可变的，这点不同于String
不同：
1 StringBuilder：线程非安全的 StringBuffer：线程安全的
2 单线程，在执行速度方面的比较：StringBuilder > StringBuffer
3.StringBuffer比StringBuilder多了一个toStringCache字段，用来在toString方法中进行缓存，每次append操作之前都先把toStringCache设置为null，若多次连续调用toString方法，可避免每次Arrays.copyOfRange(value, 0, count)操作，节省性能。
单线程StringBuffer与StringBuilder区别
这个才是我们重点讨论的，单线程下StringBuffer加了synchronized，虽然是单线程， 但是synchronized获取锁和释放锁也还是需要时间的， 而StringBuilder没有，这个就是重点区别。因此重点要讨论synchronized锁的状态，从获取锁到释放锁的过程，因此需要讨论一下锁的升级和优化。
偏向锁：
偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。
为什么要引入偏向锁？
因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。
偏向锁的升级
当线程1访问代码块并获取锁对象时，会在java对象头和栈帧中记录偏向的锁的threadID，因为偏向锁不会主动释放锁，因此以后线程1再次获取锁的时候，需要比较当前线程的threadID和Java对象头中的threadID是否一致，如果一致（还是线程1获取锁对象），则无需使用CAS来加锁、解锁；如果不一致（其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID），那么需要查看Java对象头中记录的线程1是否存活，如果没有存活，那么锁对象被重置为无锁状态，其它线程（线程2）可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程（线程1）的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1 不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。
偏向锁的取消：
偏向锁是默认开启的，而且开始时间一般是比应用程序启动慢几秒，如果不想有这个延迟，那么可以使用-XX:BiasedLockingStartUpDelay=0；
如果不想要偏向锁，那么可以通过-XX:-UseBiasedLocking = false来设置；
（2）轻量级锁
轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能
为什么要引入轻量级锁？
轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。
（3）重量级锁
重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。
轻量级锁什么时候升级为重量级锁？
线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间（称为DisplacedMarkWord），然后使用CAS把对象头中的内容替换为线程1存储的锁记录（DisplacedMarkWord）的地址；
如果在线程1复制对象头的同时（在线程1CAS之前），线程2也准备获取锁，复制了对象头到线程2的锁记录空间中，但是在线程2CAS的时候，发现线程1已经把对象头换了，线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。
但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，比如10次或者100次，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。
*注意：为了避免无用的自旋，轻量级锁一旦膨胀为重量级锁就不会再降级为轻量级锁了；偏向锁升级为轻量级锁也不能再降级为偏向锁。一句话就是锁可以升级不可以降级，但是偏向锁状态可以被重置为无锁状态。
综上可知，StringBuffer虽然是单线程，但它是有偏向锁升级过程判断的，会耗费时间，效率固然低于StringBuilder
StringBuffer与StringBuilder的应用场景
当我们在字符串缓StringBuffer与StringBuilder的应用场景冲去被多个线程使用是，JVM不能保证StringBuilder的操作是安全的，虽然他的速度最快，但是可以保证StringBuffer是可以正确操作的。当然大多数情况下就是我们是在单线程下进行的操作，所以大多数情况下是建议用StringBuilder而不用StringBuffer的，就是速度的原因。
对于三者使用的总结：
1.如果要操作少量的数据用 String
2.单线程操作字符串缓冲区 下操作大量数据 StringBuilder
3.多线程操作字符串缓冲区 下操作大量数据 StringBuffer
ArrayList LinkedList, synchronizedList
HashSet
HashSet 实现了 Set 接口，由哈希表（实际是 HashMap）提供支持。HashSet 不保证集合的迭代顺序，但允许插入 null 值。
HashSet 如何保证元素不重复？
我们只要了解了 HashSet 执行添加元素的流程，就能知道为什么 HashSet 能保证元素不重复了？
HashSet 添加元素的执行流程是：当把对象加入 HashSet 时，HashSet 会先计算对象的 hashcode 值来判断对象加入的位置，同时也会与其他加入的对象的 hashcode 值作比较，如果没有相符的 hashcode，HashSet 会假设对象没有重复出现，会将对象插入到相应的位置中。但是如果发现有相同 hashcode 值的对象，这时会调用对象的 equals() 方法来检查对象是否真的相同，如果相同，则 HashSet 就不会让重复的对象加入到 HashSet 中，这样就保证了元素的不重复。
gc 垃圾回收算法
线程池工作原理。 shutdown shutdownNow
newSingleThreadExecutor 创建“单线程化线程池”
1.单线程化的线程池中的任务，是按照提交的次序，顺序执行的
2.池中的唯一线程的存活时间是无限的
3.当池中的唯一线程正繁忙时，新提交的任务实例会进入内部的阻塞队列中，并且其阻塞队列是无界的。
总体来说，单线程化的线程池所适用的场景是：任务按照提交次序，一个任务一个任务逐个执行的场景。
newFixedThreadPool 创建“固定数量的线程池”
如果线程数量没有达到“固定数量”，则每次提交一个任务池内就创建一个新的线程，直到到达固定的数量
2.线程池的大小一旦达到“固定数量”就会保持不变，如果某个线程因为执行异常而结束，那么线程池会补充一个新线程。
3.如果池中的所有线程均在繁忙状态，对于新任务会进入阻塞队列中(无界的阻塞队列)。
使用场景：需要任务长期执行的场景。“固定数量的线程池”的线程数能够比较稳定保证一个数，能够避免频繁回收线程和创建线程，故适用于处理 CPU 密集型的任务，在 CPU 被工作线程长时间使用的情况下，能确保尽可能少的分配线程。 弊端：内部使用无界队列来存放排队任务，当大量任务超过线程池最大容量需要处理时，队列无线增大，使服务器资源迅速耗尽。
newCachedThreadPool 创建“可缓存线程池”
在接收新的异步任务 target 执行目标实例时，如果池内所有线程繁忙，此线程池会添加新线程来处理任务。
2.此线程池不会对线程池大小做限制，线程池大小完全依赖于操作系统（或者说 JVM）能够创建的最大线程大小。
3.如果部分线程空闲，也就是存量线程的数量超过了处理任务数量，那么就会回收空闲（60 秒不执行任务）线程。
适用场景：需要快速处理突发性强、耗时较短的任务场景，如 Netty 的NIO 处理场景、REST API 接口的瞬时削峰场景。“可缓存线程池”的线程数量不固定，只要有空闲线程就会被回收；接收到的新异步任务执行目标，查看是否有线程处于空闲状态，如果没有就直接创建新的线程。 弊端：线程池没有最大线程数量限制，如果大量的异步任务执行目标实例同时提交，可能导致创线程过多会而导致资源耗尽。
newScheduledThreadPool 创建“可调度线程池”
创建的线程池的好处？
1.降低资源消耗.通过重复利用自己创建的线程降低线程创建和销毁造成的消耗.
2.2.提高响应速度.当任务到达时,任务可以不需要等到线程和粗昂就爱你就能立即执行.
3.3.提高线程的可管理性.线程是稀缺资源,如果无限的创线程,不仅会消耗资源,还会降低系统的稳定性,使用线程池可以进行统一分配,调优和监控
shutdown只是将线程池的状态设置为SHUTWDOWN状态，正在执行的任务会继续执行下去，没有被执行的则中断。而shutdownNow则是将线程池的状态设置为STOP，正在执行的任务则被停止，没被执行任务的则返回。
synchronized ReentranLock 区别 ？
synchronized和ReentrantLock的区别
共同点：
1.都是用来协调多线程对共享对象、变量的访问
2.都是可重入锁，同一线程可以多次获得同一个锁
3.都保证了可见性和互斥性
不同点：
1. ReentrantLock显示地获得，释放锁，synchronized隐式获得释放锁
2. ReentrantLock可响应中断，可轮回，synchronized是不可以响应中断的
3. ReentrantLock是API级别的，synchronized是JVM级别的
4. ReentrantLock可以实现公平锁
5. ReentrantLock通过Condition可以绑定多个条件
6. 底层实现不一样，synchronized是同步阻塞，使用的是悲观并发策略，lock是同步非阻塞，采用的是乐观并发策略。
7. Lock是一个接口，而synchronized是java中的关键字，synchronized是内置的语言实现
8. synchronized 在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而 Lock 在发生异常时，如果没有主动通过 unLock()去释放锁，则很可能造成死锁现象， 因此使用 Lock 时需要在 finally 块中释放锁。
33 ThreadLocal
ThreadLocal是一个关于创建线程局部变量的类。
ThreadLocal的作用主要是做数据隔离，填充的数据只属于当前线程，变量的数据对别的线程而言是相对隔离的，在多线程环境下，如何防止自己的变量被其它线程篡改。
隔离有什么用，会用在什么场景么? 事务隔离级别
通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。而使用ThreadLocal创建的变量只能被当前线程访问，其他线程则无法访问和修改。
private void testThreadLocal() {
Thread t = new Thread() {
ThreadLocal
@Override
public void run() {
super.run();
mStringThreadLocal.set(“droidyue.com”);
mStringThreadLocal.get();
}
};
t.start();
}
ThreadLocal初始值
为ThreadLocal设置默认的get初始值，需要重写initialValue方法，下面是一段代码，我们将默认值修改成了线程的名字
ThreadLocal
@Override
protected String initialValue() {
return Thread.currentThread().getName();
}
};
底层实现的原理
ThreadLocal的set方法
1 首先获取当前线程
2 利用当前线程作为句柄获取一个ThreadLocalMap的对象
3 如果上述ThreadLocalMap对象不为空，则设置值，否则创建这个ThreadLocalMap对象并设置值
源码如下
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
下面是一个利用Thread对象作为句柄获取ThreadLocalMap对象的代码
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
上面的代码获取的实际上是Thread对象的threadLocals变量，可参考下面代码
class Thread implements Runnable {
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
}
而如果一开始设置，即ThreadLocalMap对象未创建，则新建ThreadLocalMap对象，并设置初始值。
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
总结：实际上ThreadLocal的值是放入了当前线程的一个ThreadLocalMap实例中，所以只能在本线程中访问，其他线程无法访问。
ThreadLocalMap底层结构
ThreadLocalMap呢是当前线程Thread一个叫threadLocals的变量中获取的
并未实现Map接口，而且他的Entry是继承WeakReference（弱引用）的，也没有看到HashMap中的next，所以不存在链表了。
static class ThreadLocalMap {
static class Entry extends WeakReference<ThreadLocal> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
……
}
为什么需要数组呢？没有了链表怎么解决Hash冲突呢？
用数组是因为，我们开发过程中可以一个线程可以有多个TreadLocal来存放不同类型的对象的，但是他们都将放到你当前线程的ThreadLocalMap里，所以肯定要数组来存。
至于Hash冲突，我们先看一下源码：
private void set(ThreadLocal key, Object value) { Entry[] tab = table; int len = tab.length; int i = key.threadLocalHashCode & (len-1); for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) { ThreadLocal k = e.get();
if (k == key) {
e.value = value;
return;
}
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
我从源码里面看到ThreadLocalMap在存储的时候会给每一个ThreadLocal对象一个threadLocalHashCode，在插入过程中，根据ThreadLocal对象的hash值，定位到table中的位置i，int i = key.threadLocalHashCode & (len-1)。
然后会判断一下：如果当前位置是空的，就初始化一个Entry对象放在位置i上；
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
如果位置i不为空，如果这个Entry对象的key正好是即将设置的key，那么就刷新Entry中的value；
if (k == key) {
e.value = value;
return;
}
如果位置i的不为空，而且key不等于entry，那就找下一个空位置，直到为空为止。
每个ThreadLocal对象都有一个hash值threadLocalHashCode，每初始化一个ThreadLocal对象，hash值就增加一个固定的大小0x61c88647。
在插入过程中，根据ThreadLocal对象的hash值，定位到table中的位置i，过程如下：
1、如果当前位置是空的，那么正好，就初始化一个Entry对象放在位置i上；
2、不巧，位置i已经有Entry对象了，如果这个Entry对象的key正好是即将设置的key，那么重新设置Entry中的value；
3、很不巧，位置i的Entry对象，和即将设置的key没关系，那么只能找下一个空位置；
这样的话，在get的时候，也会根据ThreadLocal对象的hash值，定位到table中的位置，然后判断该位置Entry对象中的key是否和get的key一致，如果不一致，就判断下一个位置
可以发现，set和get如果冲突严重的话，效率很低，因为ThreadLoalMap是Thread的一个属性，所以即使在自己的代码中控制了设置的元素个数，但还是不能控制其它代码的行为。
这样的话，在get的时候，也会根据ThreadLocal对象的hash值，定位到table中的位置，然后判断该位置Entry对象中的key是否和get的key一致，如果不一致，就判断下一个位置，set和get如果冲突严重的话，效率还是很低的。
以下是get的源码，是不是就感觉很好懂了：
private Entry getEntry(ThreadLocal<?> key) {
int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
if (e != null && e.get() == key)
return e;
else
return getEntryAfterMiss(key, i, e);
}
private Entry getEntryAfterMiss(ThreadLocal key, int i, Entry e) {
Entry[] tab = table;
int len = tab.length;
// get的时候一样是根据ThreadLocal获取到table的i值，然后查找数据拿到后会对比key是否相等 if (e != null && e.get() == key)。
while (e != null) {
ThreadLocal k = e.get();
// 相等就直接返回，不相等就继续查找，找到相等位置。
if (k == key)
return e;
if (k == null)
expungeStaleEntry(i);
else
i = nextIndex(i, len);
e = tab[i];
}
return null;
}
对象存放在哪里 堆
在Java中，栈内存归属于单个线程，每个线程都会有一个栈内存，其存储的变量只能在其所属线程中可见，即栈内存可以理解成线程的私有内存。
而堆内存中的对象对所有线程可见。堆内存中的对象可以被所有线程访问。
ThreadLocal实例实际上也是被其创建的类持有（更顶端应该是被线程持有）。而ThreadLocal的值其实也是被线程实例持有。
它们都是位于堆上，只是通过一些技巧将可见性修改成了线程可见。
真的只能被一个线程访问么 InheritableThreadLocal
既然上面提到了ThreadLocal只对当前线程可见，是不是说ThreadLocal的值只能被一个线程访问呢？
使用InheritableThreadLocal可以实现多个线程访问ThreadLocal的值。
如下，我们在主线程中创建一个InheritableThreadLocal的实例，然后在子线程中得到这个InheritableThreadLocal实例设置的值。
private void testInheritableThreadLocal() {
final ThreadLocal threadLocal = new InheritableThreadLocal();
threadLocal.set(“droidyue.com”);
Thread t = new Thread() {
@Override
public void run() {
super.run();
Log.i(LOGTAG, “testInheritableThreadLocal =” + threadLocal.get());
}
};
t.start();
}
上面的代码输出的日志信息为
I/MainActivity( 5046): testInheritableThreadLocal =droidyue.com
使用InheritableThreadLocal可以将某个线程的ThreadLocal值在其子线程创建时传递过去。因为在线程创建过程中，有相关的处理逻辑。
//Thread.java
private void init(ThreadGroup g, Runnable target, String name,
long stackSize, AccessControlContext acc) {
//code goes here
if (parent.inheritableThreadLocals != null)
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
/* Stash the specified stack size in case the VM cares */
this.stackSize = stackSize;
/* Set thread ID */
tid = nextThreadID();
}
上面代码就是在线程创建的时候，复制父线程的inheritableThreadLocals的数据。
会导致内存泄露么 弱引用 threadLocal.remove();
有网上讨论说ThreadLocal会导致内存泄露，原因如下
·首先ThreadLocal实例被线程的ThreadLocalMap实例持有，也可以看成被线程持有。
·如果应用使用了线程池，那么之前的线程实例处理完之后出于复用的目的依然存活
·所以，ThreadLocal设定的值被持有，导致内存泄露。
上面的逻辑是清晰的，可是ThreadLocal并不会产生内存泄露，因为ThreadLocalMap在选择key的时候，并不是直接选择ThreadLocal实例，而是ThreadLocal实例的弱引用。（无论内存是否足够，只要 JVM 开始进行垃圾回收，那些被弱引用关联的对象都会被回收）
ThreadLocal在保存的时候会把自己当做Key存在ThreadLocalMap中，正常情况应该是key和value都应该被外界强引用才对，但是现在key被设计成WeakReference弱引用了。
ThreadLocal在没有外部强引用时，发生GC时会被回收，如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露。
就比如线程池里面的线程，线程都是复用的，那么之前的线程实例处理完之后，出于复用的目的线程依然存活，所以，ThreadLocal设定的value值被持有，导致内存泄露。
按照道理一个线程使用完，ThreadLocalMap是应该要被清空的，但是现在线程被复用了。
那怎么解决？
在代码的最后使用remove就好了，我们只要记得在使用的最后用remove把值清空就好了。
remove的源码很简单，找到对应的值全部置空，这样在垃圾回收器回收的时候，会自动把他们回收掉。
那为什么ThreadLocalMap的key要设计成弱引用？
key不设置成弱引用的话就会造成和entry中value一样内存泄漏的场景。
补充一点：ThreadLocal的不足，我觉得可以通过看看netty的fastThreadLocal来弥补，大家有兴趣可以康康。
使用场景
1 实现单个线程单例以及单个线程上下文信息存储，比如交易id等
2 实现线程安全，非线程安全的对象使用ThreadLocal之后就会变得线程安全，因为每个线程都会有一个对应的实例
3 承载一些线程相关的数据，避免在方法中来回传递参数
2.Spring实现事务隔离级别
Spring采用Threadlocal的方式，来保证单个线程中的数据库操作使用的是同一个数据库连接，同时，采用这种方式可以使业务层使用事务时不需要感知并管理connection对象，通过传播级别，巧妙地管理多个事务配置之间的切换，挂起和恢复。Spring框架里面就是用的ThreadLocal来实现这种隔离，主要是在TransactionSynchronizationManager这个类里面
3.线程池加上ThreadLocal包装SimpleDataFormat，再调用initialValue让每个线程有一个SimpleDataFormat的副本，从而解决了线程安全的问题，也提高了性能。
4.很多场景的cookie，session等数据隔离都是通过ThreadLocal去做实现的
JVM内存结构 VS Java内存模型 VS Java对象模型
JMM是一种规范，目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。
Java虚拟机规范中定义了Java内存模型（Java Memory Model，JMM），用于屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效果，JMM规范了Java虚拟机与计算机内存是如何协同工作的：规定了一个线程如何和何时可以看到由其他线程修改过后的共享变量的值，以及在必须时如何同步的访问共享变量。
为了保证共享内存的正确性（可见性、有序性、原子性），内存模型定义了共享内存系统中多线程程序读写操作行为的规范。通过这些规则来规范对内存的读写操作，从而保证指令执行的正确性。它与处理器有关、与缓存有关、与并发有关、与编译器也有关。他解决了CPU多级缓存、处理器优化、指令重排等导致的内存访问问题，保证了并发场景下的一致性、原子性和有序性。
在开发多线程的代码的时候，我们可以直接使用synchronized等关键字来控制并发，从来就不需要关心底层的编译器优化、缓存一致性等问题。所以，Java内存模型，除了定义了一套规范，还提供了一系列原语，封装了底层实现后，供开发者直接使用。
JVM内存结构
Java代码是要运行在虚拟机上的，而虚拟机在执行Java程序的过程中会把所管理的内存划分为若干个不同的数据区域，这些区域都有各自的用途。其中有些区域随着虚拟机进程的启动而存在，而有些区域则依赖用户线程的启动和结束而建立和销毁。
Java内存模型
Java内存模型看上去和Java内存结构（JVM内存结构）差不多，很多人会误以为两者是一回事儿，这也就导致面试过程中经常答非所为。
在前面的关于JVM的内存结构的图中，我们可以看到，其中Java堆和方法区的区域是多个线程共享的数据区域。也就是说，多个线程可能可以操作保存在堆或者方法区中的同一个数据。这也就是我们常说的“Java的线程间通过共享内存进行通信”。
Java内存模型是根据英文Java Memory Model（JMM）翻译过来的。其实JMM并不像JVM内存结构一样是真实存在的。他只是一个抽象的概念。JMM是和多线程相关的，他描述了一组规则或规范，这个规范定义了一个线程对共享变量的写入时对另一个线程是可见的。
那么，简单总结下，Java的多线程之间是通过共享内存进行通信的，而由于采用共享内存进行通信，在通信过程中会存在一系列如可见性、原子性、顺序性等问题，而JMM就是围绕着多线程通信以及与其相关的一系列特性而建立的模型。JMM定义了一些语法集，这些语法集映射到Java语言中就是volatile、synchronized等关键字。
在Java中，JMM是一个非常重要的概念，正是由于有了JMM，Java的并发编程才能避免很多问题。这里就不对Java内存模型做更加详细的介绍了，想了解更多的朋友可以参考《Java并发编程的艺术》。
Java对象模型
Java是一种面向对象的语言，而Java对象在JVM中的存储也是有一定的结构的。而这个关于Java对象自身的存储模型称之为Java对象模型。
HotSpot虚拟机中，设计了一个OOP-Klass Model。OOP（Ordinary Object Pointer）指的是普通对象指针，而Klass用来描述对象实例的具体类型。
每一个Java类，在被JVM加载的时候，JVM会给这个类创建一个instanceKlass，保存在方法区，用来在JVM层表示该Java类。当我们在Java代码中，使用new创建一个对象的时候，JVM会创建一个instanceOopDesc对象，这个对象中包含了对象头以及实例数据。
这就是一个简单的Java对象的OOP-Klass模型，即Java对象模型。
总结
我们再来区分下JVM内存结构、 Java内存模型 以及 Java对象模型 三个概念。
JVM内存结构，和Java虚拟机的运行时区域有关。
Java内存模型，和Java的并发编程有关。
Java对象模型，和Java对象在虚拟机中的表现形式有关。
Java内存模型
为什么要有内存模型
在介绍Java内存模型之前，先来看一下到底什么是计算机内存模型，然后再来看Java内存模型在计算机内存模型的基础上做了哪些事情。要说计算机的内存模型，就要说一下一段古老的历史，看一下为什么要有内存模型。
内存模型，英文名Memory Model，他是一个很老的老古董了。他是与计算机硬件有关的一个概念。那么我先给你介绍下他和硬件到底有啥关系。
CPU和缓存一致性
我们应该都知道，计算机在执行程序的时候，每条指令都是在CPU中执行的，而执行的时候，又免不了要和数据打交道。而计算机上面的数据，是存放在主存当中的，也就是计算机的物理内存啦。
刚开始，还相安无事的，但是随着CPU技术的发展，CPU的执行速度越来越快。而由于内存的技术并没有太大的变化，所以从内存中读取和写入数据的过程和CPU的执行速度比起来差距就会越来越大,这就导致CPU每次操作内存都要耗费很多等待时间。
这就像一家创业公司，刚开始，创始人和员工之间工作关系其乐融融，但是随着创始人的能力和野心越来越大，逐渐和员工之间出现了差距，普通员工原来越跟不上CEO的脚步。老板的每一个命令，传到到基层员工之后，由于基层员工的理解能力、执行能力的欠缺，就会耗费很多时间。这也就无形中拖慢了整家公司的工作效率。
可是，不能因为内存的读写速度慢，就不发展CPU技术了吧，总不能让内存成为计算机处理的瓶颈吧。
所以，人们想出来了一个好的办法，就是在CPU和内存之间增加高速缓存。缓存的概念大家都知道，就是保存一份数据拷贝。他的特点是速度快，内存小，并且昂贵。
那么，程序的执行过程就变成了：
当程序在运行过程中，会将运算需要的数据从主存复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。
之后，这家公司开始设立中层管理人员，管理人员直接归CEO领导，领导有什么指示，直接告诉管理人员，然后就可以去做自己的事情了。管理人员负责去协调底层员工的工作。因为管理人员是了解手下的人员以及自己负责的事情的。所以，大多数时候，公司的各种决策，通知等，CEO只要和管理人员之间沟通就够了。
而随着CPU能力的不断提升，一层缓存就慢慢的无法满足要求了，就逐渐的衍生出多级缓存。
按照数据读取顺序和与CPU结合的紧密程度，CPU缓存可以分为一级缓存（L1），二级缓存（L2），部分高端CPU还具有三级缓存（L3），每一级缓存中所储存的全部数据都是下一级缓存的一部分。
这三种缓存的技术难度和制造成本是相对递减的，所以其容量也是相对递增的。
那么，在有了多级缓存之后，程序的执行就变成了：
当CPU要读取一个数据时，首先从一级缓存中查找，如果没有找到再从二级缓存中查找，如果还是没有就从三级缓存或内存中查找。
随着公司越来越大，老板要管的事情越来越多，公司的管理部门开始改革，开始出现高层，中层，底层等管理者。一级一级之间逐层管理。
单核CPU只含有一套L1，L2，L3缓存；如果CPU含有多个核心，即多核CPU，则每个核心都含有一套L1（甚至和L2）缓存，而共享L3（或者和L2）缓存。
公司也分很多种，有些公司只有一个大Boss，他一个人说了算。但是有些公司有比如联席总经理、合伙人等机制。
单核CPU就像一家公司只有一个老板，所有命令都来自于他，那么就只需要一套管理班底就够了。
多核CPU就像一家公司是由多个合伙人共同创办的，那么，就需要给每个合伙人都设立一套供自己直接领导的高层管理人员，多个合伙人共享使用的是公司的底层员工
还有的公司，不断壮大，开始差分出各个子公司。各个子公司就是多个CPU了，互相之前没有共用的资源。互不影响。
下图为一个单CPU双核的缓存结构。
随着计算机能力不断提升，开始支持多线程。那么问题就来了。我们分别来分析下单线程、多线程在单核CPU、多核CPU中的影响。
单线程。cpu核心的缓存只被一个线程访问。缓存独占，不会出现访问冲突等问题。
单核CPU，多线程。进程中的多个线程会同时访问进程中的共享数据，CPU将某块内存加载到缓存后，不同线程在访问相同的物理地址的时候，都会映射到相同的缓存位置，这样即使发生线程的切换，缓存仍然不会失效。但由于任何时刻只能有一个线程在执行，因此不会出现缓存访问冲突。
多核CPU，多线程。每个核都至少有一个L1 缓存。多个线程访问进程中的某个共享内存，且这多个线程分别在不同的核心上执行，则每个核心都会在各自的cache中保留一份共享内存的缓冲。由于多核是可以并行的，可能会出现多个线程同时写各自的缓存的情况，而各自的cache之间的数据就有可能不同。
在CPU和主存之间增加缓存，在多线程场景下就可能存在缓存一致性问题，也就是说，在多核CPU中，每个核的自己的缓存中，关于同一个数据的缓存内容可能不一致。
如果这家公司的命令都是串行下发的话，那么就没有任何问题。
如果这家公司的命令都是并行下发的话，并且这些命令都是由同一个CEO下发的，这种机制是也没有什么问题。因为他的命令执行者只有一套管理体系。
如果这家公司的命令都是并行下发的话，并且这些命令是由多个合伙人下发的，这就有问题了。因为每个合伙人只会把命令下达给自己直属的管理人员，而多个管理人员管理的底层员工可能是公用的。
比如，合伙人1要辞退员工a，合伙人2要给员工a升职，升职后的话他再被辞退需要多个合伙人开会决议。两个合伙人分别把命令下发给了自己的管理人员。合伙人1命令下达后，管理人员a在辞退了员工后，他就知道这个员工被开除了。而合伙人2的管理人员2这时候在没得到消息之前，还认为员工a是在职的，他就欣然的接收了合伙人给他的升职a的命令。
处理器优化和指令重排
上面提到在在CPU和主存之间增加缓存，在多线程场景下会存在缓存一致性问题。除了这种情况，还有一种硬件问题也比较重要。那就是为了使处理器内部的运算单元能够尽量的被充分利用，处理器可能会对输入代码进行乱序执行处理。这就是处理器优化。
除了现在很多流行的处理器会对代码进行优化乱序处理，很多编程语言的编译器也会有类似的优化，比如Java虚拟机的即时编译器（JIT）也会做指令重排。
可想而知，如果任由处理器优化和编译器对指令重排的话，就可能导致各种各样的问题。
关于员工组织调整的情况，如果允许人事部在接到多个命令后进行随意拆分乱序执行或者重排的话，那么对于这个员工以及这家公司的影响是非常大的。
并发编程的问题
前面说的和硬件有关的概念你可能听得有点蒙，还不知道他到底和软件有啥关系。但是关于并发编程的问题你应该有所了解，比如原子性问题，可见性问题和有序性问题。
其实，原子性问题，可见性问题和有序性问题。是人们抽象定义出来的。而这个抽象的底层问题就是前面提到的缓存一致性问题、处理器优化问题和指令重排问题等。
这里简单回顾下这三个问题，并不准备深入展开，感兴趣的读者可以自行学习。我们说，并发编程，为了保证数据的安全，需要满足以下三个特性：
原子性是指在一个操作中就是cpu不可以在中途暂停然后再调度，既不被中断操作，要不执行完成，要不就不执行。
可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
有序性即程序执行的顺序按照代码的先后顺序执行。
有没有发现，缓存一致性问题其实就是可见性问题。而处理器优化是可以导致原子性问题的。指令重排即会导致有序性问题。所以，后文将不再提起硬件层面的那些概念，而是直接使用大家熟悉的原子性、可见性和有序性。
什么是内存模型
前面提到的，缓存一致性问题、处理器优化的指令重排问题是硬件的不断升级导致的。那么，有没有什么机制可以很好的解决上面的这些问题呢？
最简单直接的做法就是废除处理器和处理器的优化技术、废除CPU缓存，让CPU直接和主存交互。但是，这么做虽然可以保证多线程下的并发问题。但是，这就有点因噎废食了。
所以，为了保证并发编程中可以满足原子性、可见性及有序性。有一个重要的概念，那就是——内存模型。
为了保证共享内存的正确性（可见性、有序性、原子性），内存模型定义了共享内存系统中多线程程序读写操作行为的规范。通过这些规则来规范对内存的读写操作，从而保证指令执行的正确性。它与处理器有关、与缓存有关、与并发有关、与编译器也有关。他解决了CPU多级缓存、处理器优化、指令重排等导致的内存访问问题，保证了并发场景下的一致性、原子性和有序性。
内存模型解决并发问题主要采用两种方式：限制处理器优化和使用内存屏障。本文就不深入底层原理来展开介绍了，感兴趣的朋友可以自行学习。
什么是Java内存模型
前面介绍过了计算机内存模型，这是解决多线程场景下并发问题的一个重要规范。那么具体的实现是如何的呢，不同的编程语言，在实现上可能有所不同。
我们知道，Java程序是需要运行在Java虚拟机上面的，Java内存模型（Java Memory Model ,JMM）就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。
Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。
而JMM就作用于工作内存和主存之间数据同步过程。他规定了如何做数据同步以及什么时候做数据同步。
这里面提到的主内存和工作内存，读者可以简单的类比成计算机内存模型中的主存和缓存的概念。特别需要注意的是，主内存和工作内存与JVM内存结构中的Java堆、栈、方法区等并不是同一个层次的内存划分，无法直接类比。《深入理解Java虚拟机》中认为，如果一定要勉强对应起来的话，从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分。工作内存则对应于虚拟机栈中的部分区域。
所以，再来总结下，JMM是一种规范，目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。
Java内存模型的实现
了解Java多线程的朋友都知道，在Java中提供了一系列和并发处理相关的关键字，比如volatile、synchronized、final、concurren包等。其实这些就是Java内存模型封装了底层的实现后提供给程序员使用的一些关键字。
在开发多线程的代码的时候，我们可以直接使用synchronized等关键字来控制并发，从来就不需要关心底层的编译器优化、缓存一致性等问题。所以，Java内存模型，除了定义了一套规范，还提供了一系列原语，封装了底层实现后，供开发者直接使用。
本文并不准备把所有的关键字逐一介绍其用法，因为关于各个关键字的用法，网上有很多资料。读者可以自行学习。本文还有一个重点要介绍的就是，我们前面提到，并发编程要解决原子性、有序性和一致性的问题，我们就再来看下，在Java中，分别使用什么方式来保证。
原子性
在Java中，为了保证原子性，提供了两个高级的字节码指令monitorenter和monitorexit。在synchronized的实现原理文章中，介绍过，这两个字节码，在Java中对应的关键字就是synchronized。
因此，在Java中可以使用synchronized来保证方法和代码块内的操作是原子性的。
可见性
Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值的这种依赖主内存作为传递媒介的方式来实现的。
Java中的volatile关键字提供了一个功能，那就是被其修饰的变量在被修改后可以立即同步到主内存，被其修饰的变量在每次是用之前都从主内存刷新。因此，可以使用volatile来保证多线程操作时变量的可见性。
除了volatile，Java中的synchronized和final两个关键字也可以实现可见性。只不过实现方式不同，这里不再展开了。
有序性
在Java中，可以使用synchronized和volatile来保证多线程之间操作的有序性。实现方式有所区别：
volatile关键字会禁止指令重排。synchronized关键字保证同一时刻只允许一条线程操作。
好了，这里简单的介绍完了Java并发编程中解决原子性、可见性以及有序性可以使用的关键字。读者可能发现了，好像synchronized关键字是万能的，他可以同时满足以上三种特性，这其实也是很多人滥用synchronized的原因。
但是synchronized是比较影响性能的，虽然编译器提供了很多锁优化技术，但是也不建议过度使用。
内存模型是怎么解决缓存一致性问题的？
http://www.hollischuang.com/archives/2662
我们在文章中提到过，由于CPU和主存的处理速度上存在一定差别，为了匹配这种差距，提升计算机能力，人们在CPU和主存之间增加了多层高速缓存。每个CPU会有L1、L2甚至L3缓存，在多核计算机中会有多个CPU，那么就会存在多套缓存，那么这多套缓存之间的数据就可能出现不一致的现象。为了解决这个问题，有了内存模型。内存模型定义了共享内存系统中多线程程序读写操作行为的规范。通过这些规则来规范对内存的读写操作，从而保证指令执行的正确性。
缓存一致性是由于引入缓存而导致的问题，所以，这是很多CPU厂商必须解决的问题。为了解决前面提到的缓存数据不一致的问题，人们提出过很多方案，通常来说有以下2种方案：
1、通过在总线加LOCK#锁的方式。
2、通过缓存一致性协议（Cache Coherence Protocol）。
在早期的CPU当中，是通过在总线上加LOCK#锁的形式来解决缓存不一致的问题。因为CPU和其他部件进行通信都是通过总线来进行的，如果对总线加LOCK#锁的话，也就是说阻塞了其他CPU对其他部件访问（如内存），从而使得只能有一个CPU能使用这个变量的内存。在总线上发出了LCOK#锁的信号，那么只有等待这段代码完全执行完毕之后，其他CPU才能从其内存读取变量，然后进行相应的操作。这样就解决了缓存不一致的问题。
但是由于在锁住总线期间，其他CPU无法访问内存，会导致效率低下。因此出现了第二种解决方案，通过缓存一致性协议来解决缓存一致性问题。
缓存一致性协议
缓存一致性协议（Cache Coherence Protocol），最出名的就是Intel 的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。
MESI的核心的思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。
在MESI协议中，每个缓存可能有有4个状态，它们分别是：
M(Modified)：这行数据有效，数据被修改了，和内存中的数据不一致，数据只存在于本Cache中。
E(Exclusive)：这行数据有效，数据和内存中的数据一致，数据只存在于本Cache中。
S(Shared)：这行数据有效，数据和内存中的数据一致，数据存在于很多Cache中。
I(Invalid)：这行数据无效。
关于MESI的更多细节这里就不详细介绍了，读者只要知道，MESI是一种比较常用的缓存一致性协议，他可以用来解决缓存之间的数据一致性问题就可以了。
但是，值得注意的是，传统的MESI协议中有两个行为的执行成本比较大。
一个是将某个Cache Line标记为Invalid状态，另一个是当某Cache Line当前状态为Invalid时写入新的数据。所以CPU通过Store Buffer和Invalidate Queue组件来降低这类操作的延时。
当一个CPU进行写入时，首先会给其它CPU发送Invalid消息，然后把当前写入的数据写入到Store Buffer中。然后异步在某个时刻真正的写入到Cache中。
当前CPU核如果要读Cache中的数据，需要先扫描Store Buffer之后再读取Cache。
但是此时其它CPU核是看不到当前核的Store Buffer中的数据的，要等到Store Buffer中的数据被刷到了Cache之后才会触发失效操作。
而当一个CPU核收到Invalid消息时，会把消息写入自身的Invalidate Queue中，随后异步将其设为Invalid状态。
和Store Buffer不同的是，当前CPU核心使用Cache时并不扫描Invalidate Queue部分，所以可能会有极短时间的脏读问题。
所以，为了解决缓存的一致性问题，比较典型的方案是MESI缓存一致性协议。
MESI协议，可以保证缓存的一致性，但是无法保证实时性。
内存模型
内存模型（Memory Model）如果扩展开来说的话，通常指的是内存一致性模型（Memory Sequential Consistency Model）
前面我们提到过缓存一致性，这里又要说内存一致性，不是故意要把读者搞蒙，而是希望通过对比让读者更加清楚。
缓存一致性（Cache Coherence），解决是多个缓存副本之间的数据的一致性问题。
内存一致性（Memory Consistency），保证的是多线程程序访问内存时可以读到什么值。
我们首先看以下程序：
初始：x=0 y=0
Thread1：
S1：x=1
L1：r1=y
Thread2：
S2：y=2
L2：r2=x
其中，S1、S2、L1、L2是语句代号（S表示Store，L表示Load）；r1和r2是两个寄存器。x和y是两个不同的内存变量。两个线程执行完之后，r1和r2可能是什么值？
注意到线程是并发、交替执行的，下面是可能的执行顺序和相应结果：
S1 L1 S2 L2 那么r1=0 r2=2
S1 S2 L1 L2 那么r1=2 r2=1
S2 L2 S1 L1 那么r1=2 r2=0
这些都是意料之内、情理之中的。但是在x86体系结构下，很可能得到r1=0 r2=0这样的结果。
如果没有Memory Consistency，程序员写的程序代码的输出结果是不确定的。
因此，Memory Consistency就是程序员（编程语言）、编译器、CPU间的一种协议。这个协议保证了程序访问内存时会得到什么值。
简单点说，内存一致性，就是保证并发场景下的程序运行结果和程序员预期是一样的（当然，要通过加锁等方式），包括的就是并发编程中的原子性、有序性和可见性。而缓存一致性说的就是并发编程中的可见性。
在很多内存模型的实现中，关于缓存一致性的保证都是通过硬件层面缓存一致性协议来保证的。需要注意的是，这里提到的内存模型，是计算机内存模型，而非Java内存模型。
总结
缓存一致性问题。硬件层面的问题，指的是由于多核计算机中有多套缓存，各个缓存之间的数据不一致性问题。
PS：这里还需要再重复一遍，Java多线程中，每个线程都有自己的工作内存，需要和主存进行交互。这里的工作内存和计算机硬件的缓存并不是一回事儿，只是可以相互类比。所以，并发编程的可见性问题，是因为各个线程之间的本地内存数据不一致导致的，和计算机缓存并无关系。
缓存一致性协议。用来解决缓存一致性问题的，常用的是MESI协议。
内存一致性模型。屏蔽计算机硬件问题，主要来解决并发编程中的原子性、有序性和一致性问题。
实现内存一致性模型的时候可能会用到缓存一致性模型。
Synchronized的实现原理
http://www.hollischuang.com/archives/1883
synchronized，是Java中用于解决并发情况下数据同步访问的一个很重要的关键字。当我们想要保证一个共享资源在同一时间只会被一个线程访问到时，我们可以在代码中使用synchronized关键字对类或者对象加锁。
反编译后，
对于同步方法，JVM采用ACC_SYNCHRONIZED标记符来实现同步。
方法级的同步是隐式的。同步方法的常量池中会有一个ACC_SYNCHRONIZED标志。当某个线程要访问某个方法的时候，会检查是否有ACC_SYNCHRONIZED，如果有设置，则需要先获得监视器锁，然后开始执行方法，方法执行之后再释放监视器锁。这时如果其他线程来请求执行方法，会因为无法获得监视器锁而被阻断住。值得注意的是，如果在方法执行过程中，发生了异常，并且方法内部并没有处理该异常，那么在异常被抛到方法外面之前监视器锁会被自动释放。
对于同步代码块。JVM采用monitorenter、monitorexit两个指令来实现同步。
可以把执行monitorenter指令理解为加锁，执行monitorexit理解为释放锁。 每个对象维护着一个记录着被锁次数的计数器。未被锁定的对象的该计数器为0，当一个线程获得锁（执行monitorenter）后，该计数器自增变为 1 ，当同一个线程再次获得该对象的锁的时候，计数器再次自增。当同一个线程释放锁（执行monitorexit指令）的时候，计数器再自减。当计数器为0的时候。锁将被释放，其他线程便可以获得锁。
总结
同步方法通过ACC_SYNCHRONIZED关键字隐式的对方法进行加锁。当线程要执行的方法被标注上ACC_SYNCHRONIZED时，需要先获得锁才能执行该方法。
同步代码块通过monitorenter和monitorexit执行来进行加锁。当线程执行到monitorenter的时候要先获得所锁，才能执行后面的方法。当线程执行到monitorexit的时候则要释放锁。
每个对象自身维护这一个被加锁次数的计数器，当计数器数字为0时表示可以被任意线程获得锁。当计数器不为0时，只有获得锁的线程才能再次获得锁。即可重入锁。
Moniter的实现原理
http://www.hollischuang.com/archives/2030
为什么synchronized无法禁止指令重排，却能保证有序性？
http://www.hollischuang.com/archives/4460
先我们要分析下这道题，不得不说这个面试官还是有一定的水平的，这简单的一个问题，其实里面还是包含了很多信息的，要想回答好这个问题，面试者至少要知道一下概念：
Java内存模型、并发编程有序性问题、指令重排、synchronized锁、可重入锁、排它锁、as-if-serial语义、单线程&多线程
所以，这道题的正确回答姿势是怎样的呢？
这是个好问题，这个问题我曾经也思考过，也查阅过很多资料，甚至还去看过hotsopt的源码。
不管三七二十一，上来先舔一波，然后表示下自己求知好学的态度。
为了进一步提升计算机各方面能力，在硬件层面做了很多优化，如处理器优化和指令重排等，但是这些技术的引入就会导致有序性问题。
先告诉面试官你知道什么是有序性问题，也知道是什么原因导致的有序性问题
我们也知道，最好的解决有序性问题的办法，就是禁止处理器优化和指令重排，就像volatile中使用内存屏障一样。
表明你知道啥是指令重排，也知道他的实现原理
但是，虽然很多硬件都会为了优化做一些重排，但是在Java中，不管怎么排序，都不能影响单线程程序的执行结果。这就是as-if-serial语义，所有硬件优化的前提都是必须遵守as-if-serial语义。
重点！解释下什么是as-if-serial语义，因为这是这道题的第一个关键词，答上来就对了一半了
再说下synchronized，他是Java提供的锁，可以通过他对Java中的对象加锁，并且他是一种排他的、可重入的锁。
装X项，不留痕迹的展示自己对锁了解的比较多
所以，当某个线程执行到一段被synchronized修饰的代码之前，会先进行加锁，执行完之后再进行解锁。在加锁之后，解锁之前，其他线程是无法再次获得锁的，只有这条加锁线程可以重复获得该锁。
介绍synchronized的原理，这是本题的第二个关键点，到这里基本就可以拿满分了。
synchronized通过排他锁的方式就保证了同一时间内，被synchronized修饰的代码是单线程执行的。所以呢，这就满足了as-if-serial语义的一个关键前提，那就是单线程，因为有as-if-serial语义保证，单线程的有序性就天然存在了。
volatile关键字
https://juejin.cn/post/6844903656274264078
https://juejin.cn/post/6844903520760496141
https://www.cnblogs.com/dolphin0520/p/3920373.html
https://monkeysayhi.github.io/2016/11/29/volatile%E5%85%B3%E9%94%AE%E5%AD%97%E7%9A%84%E4%BD%9C%E7%94%A8%E3%80%81%E5%8E%9F%E7%90%86/
volatile的用法
volatile通常被比喻成”轻量级的synchronized”，也是Java并发编程中比较重要的一个关键字。和synchronized不同，volatile是一个变量修饰符，只能用来修饰变量。无法修饰方法及代码块等。
volatile的用法比较简单，只需要在声明一个可能被多线程同时访问的变量时，使用volatile修饰就可以了。
public class Singleton {
private volatile static Singleton singleton;
private Singleton (){}
public static Singleton getSingleton() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
} 复制代码
如以上代码，是一个比较典型的使用双重锁校验的形式实现单例的，其中使用volatile关键字修饰可能被多个线程同时访问到的singleton。
volatile的原理
在再有人问你Java内存模型是什么，就把这篇文章发给他中我们曾经介绍过，为了提高处理器的执行速度，在处理器和内存之间增加了多级缓存来提升。但是由于引入了多级缓存，就存在缓存数据不一致问题。
但是，对于volatile变量，当对volatile变量进行写操作的时候，JVM会向处理器发送一条lock前缀的指令，将这个缓存中的变量回写到系统主存中。
但是就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题，所以在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议
缓存一致性协议：每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器要对这个数据进行修改操作的时候，会强制重新从系统内存里把数据读到处理器缓存里。
所以，如果一个变量被volatile所修饰的话，在每次数据变化之后，其值都会被强制刷入主存。而其他处理器的缓存由于遵守了缓存一致性协议，也会把这个变量的值从主存加载到自己的缓存中。这就保证了一个volatile在并发编程中，其值在多个缓存中是可见的。
volatile与可见性
可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。所以，就可能出现线程1改了某个变量的值，但是线程2不可见的情况。
前面的关于volatile的原理中介绍过了，Java中的volatile关键字提供了一个功能，那就是被其修饰的变量在被修改后可以立即同步到主内存，被其修饰的变量在每次是用之前都从主内存刷新。因此，可以使用volatile来保证多线程操作时变量的可见性。
volatile与有序性
有序性即程序执行的顺序按照代码的先后顺序执行。
我们在再有人问你Java内存模型是什么，就把这篇文章发给他中分析过：除了引入了时间片以外，由于处理器优化和指令重排等，CPU还可能对输入代码进行乱序执行，比如load->add->save 有可能被优化成load->save->add 。这就是可能存在有序性问题。
而volatile除了可以保证数据的可见性之外，还有一个强大的功能，那就是他可以禁止指令重排优化等。
普通的变量仅仅会保证在该方法的执行过程中所依赖的赋值结果的地方都能获得正确的结果，而不能保证变量的赋值操作的顺序与程序代码中的执行顺序一致。
volatile可以禁止指令重排，这就保证了代码的程序会严格按照代码的先后顺序执行。这就保证了有序性。被volatile修饰的变量的操作，会严格按照代码顺序执行，load->add->save 的执行顺序就是：load、add、save。
volatile与原子性
原子性是指一个操作是不可中断的，要全部执行完成，要不就都不执行。
线程是CPU调度的基本单位。CPU有时间片的概念，会根据不同的调度算法进行线程调度。当一个线程获得时间片之后开始执行，在时间片耗尽之后，就会失去CPU使用权。所以在多线程场景下，由于时间片在线程间轮换，就会发生原子性问题。
在上一篇文章中，我们介绍synchronized的时候，提到过，为了保证原子性，需要通过字节码指令monitorenter和monitorexit，但是volatile和这两个指令之间是没有任何关系的。
所以，volatile是不能保证原子性的。
在以下两个场景中可以使用volatile来代替synchronized：
1、运算结果并不依赖变量的当前值，或者能够确保只有单一的线程会修改变量的值。
2、变量不需要与其他状态变量共同参与不变约束。
除以上场景外，都需要使用其他方式来保证原子性，如synchronized或者concurrent包。
总结与思考
我们介绍过了volatile关键字和synchronized关键字。现在我们知道，synchronized可以保证原子性、有序性和可见性。而volatile却只能保证有序性和可见性。
那么，我们再来看一下双重校验锁实现的单例，已经使用了synchronized，为什么还需要volatile？
public class Singleton {
private volatile static Singleton singleton;
private Singleton (){}
public static Singleton getSingleton() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
Synchronized vs volatile
我们都知道synchronized其实是一种加锁机制，那么既然是锁，天然就具备以下几个缺点：
1、有性能损耗 适应性自旋、锁消除、锁粗化、轻量级锁和偏向锁等
无论是使用同步方法还是同步代码块，在同步操作之前还是要进行加锁，同步操作之后需要进行解锁，这个加锁、解锁的过程是要有性能损耗的。
关于二者的性能对比，由于虚拟机对锁实行的许多消除和优化，使得我们很难量化这两者之间的性能差距，但是我们可以确定的一个基本原则是：volatile变量的读操作的性能小号普通变量几乎无差别，但是写操作由于需要插入内存屏障所以会慢一些，即便如此，volatile在大多数场景下也比锁的开销要低。
2、产生阻塞
synchronize的实现原理，无论是同步方法还是同步代码块，无论是ACC_SYNCHRONIZED还是monitorenter、monitorexit都是基于Monitor实现的。
基于Monitor对象，当多个线程同时访问一段同步代码时，首先会进入Entry Set，当有一个线程获取到对象的锁之后，才能进行The Owner区域，其他线程还会继续在Entry Set等待。并且当某个线程调用了wait方法后，会释放锁并进入Wait Set等待。
所以，synchronize实现的锁本质上是一种阻塞锁，也就是说多个线程要排队访问同一个共享对象。
而volatile是Java虚拟机提供的一种轻量级同步机制，他是基于内存屏障实现的。说到底，他并不是锁，所以他不会有synchronized带来的阻塞和性能损耗的问题。
volatile的附加功能
除了前面我们提到的volatile比synchronized性能好以外，volatile其实还有一个很好的附加功能，那就是禁止指令重排。
我们先来举一个例子，看一下如果只使用synchronized而不使用volatile会发生什么问题，就拿我们比较熟悉的单例模式来看。
我们通过双重校验锁的方式实现一个单例，这里不使用volatile关键字：
1 public class Singleton {
2 private static Singleton singleton;
3 private Singleton (){}
4 public static Singleton getSingleton() {
5 if (singleton == null) {
6 synchronized (Singleton.class) {
7 if (singleton == null) {
8 singleton = new Singleton();
9 }
10 }
11 }
12 return singleton;
13 }
14 }
以上代码，我们通过使用synchronized对Singleton.class进行加锁，可以保证同一时间只有一个线程可以执行到同步代码块中的内容，也就是说singleton = new Singleton()这个操作只会执行一次，这就是实现了一个单例。
但是，当我们在代码中使用上述单例对象的时候有可能发生空指针异常。这是一个比较诡异的情况。
我们假设Thread1 和 Thread2两个线程同时请求Singleton.getSingleton方法的时候：
Step1 ,Thread1执行到第8行，开始进行对象的初始化。
Step2 ,Thread2执行到第5行，判断singleton == null。
Step3 ,Thread2经过判断发现singleton ！= null，所以执行第12行，返回singleton。 Step4 ,Thread2拿到singleton对象之后，开始执行后续的操作，比如调用singleton.call()。
以上过程，看上去并没有什么问题，但是，其实，在Step4，Thread2在调用singleton.call()的时候，是有可能抛出空指针异常的。
之所有会有NPE抛出，是因为在Step3，Thread2拿到的singleton对象并不是一个完整的对象。
我们这里来分析一下，singleton = new Singleton();这行代码到底做了什么事情，大致过程如下：
1、虚拟机遇到new指令，到常量池定位到这个类的符号引用。
2、检查符号引用代表的类是否被加载、解析、初始化过。
3、虚拟机为对象分配内存。
4、虚拟机将分配到的内存空间都初始化为零值。
5、虚拟机对对象进行必要的设置。
6、执行方法，成员变量进行初始化。
7、将对象的引用指向这个内存区域。
我们把这个过程简化一下，简化成3个步骤：
a、JVM为对象分配一块内存M b、在内存M上为对象进行初始化 c、将内存M的地址复制给singleton变量
因为将内存的地址赋值给singleton变量是最后一步，所以Thread1在这一步骤执行之前，Thread2在对singleton==null进行判断一直都是true的，那么他会一直阻塞，直到Thread1将这一步骤执行完。
但是，以上过程并不是一个原子操作，并且编译器可能会进行重排序，如果以上步骤被重排成：
a、JVM为对象分配一块内存M
c、将内存的地址复制给singleton变量
b、在内存M上为对象进行初始化
这样的话，Thread1会先执行内存分配，在执行变量赋值，最后执行对象的初始化，那么，也就是说，在Thread1还没有为对象进行初始化的时候，Thread2进来判断singleton==null就可能提前得到一个false，则会返回一个不完整的sigleton对象，因为他还未完成初始化操作。
这种情况一旦发生，我们拿到了一个不完整的singleton对象，当尝试使用这个对象的时候就极有可能发生NPE异常。
那么，怎么解决这个问题呢？因为指令重排导致了这个问题，那就避免指令重排就行了。
所以，volatile就派上用场了，因为volatile可以避免指令重排。只要将代码改成以下代码，就可以解决这个问题：
1 public class Singleton {
2 private volatile static Singleton singleton;
3 private Singleton (){}
4 public static Singleton getSingleton() {
5 if (singleton == null) {
6 synchronized (Singleton.class) {
7 if (singleton == null) {
8 singleton = new Singleton();
9 }
10 }
11 }
12 return singleton;
13 }
14 }
对singleton使用volatile约束，保证他的初始化过程不会被指令重排。
synchronized的有序性保证呢？
看到这里可能有朋友会问了，说到底上面问题还是个有序性的问题，不是说synchronized是可以保证有序性的么，这里为什么就不行了呢？
首先，可以明确的一点是：synchronized是无法禁止指令重排和处理器优化的。那么他是如何保证的有序性呢？
这就要再把有序性的概念扩展一下了。Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有操作都是天然有序的。如果在一个线程中观察另一个线程，所有操作都是无序的。
以上这句话也是《深入理解Java虚拟机》中的原句，但是怎么理解呢？周志明并没有详细的解释。这里我简单扩展一下，这其实和as-if-serial语义有关。
as-if-serial语义的意思指：不管怎么重排序，单线程程序的执行结果都不能被改变。编译器和处理器无论如何优化，都必须遵守as-if-serial语义。
这里不对as-if-serial语义详细展开了，简单说就是，as-if-serial语义保证了单线程中，不管指令怎么重排，最终的执行结果是不能被改变的。
那么，我们回到刚刚那个双重校验锁的例子，站在单线程的角度，也就是只看Thread1的话，因为编译器会遵守as-if-serial语义，所以这种优化不会有任何问题，对于这个线程的执行结果也不会有任何影响。
但是，Thread1内部的指令重排却对Thread2产生了影响。
那么，我们可以说，synchronized保证的有序性是多个线程之间的有序性，即被加锁的内容要按照顺序被多个线程执行。但是其内部的同步代码还是会发生重排序，只不过由于编译器和处理器都遵循as-if-serial语义，所以我们可以认为这些重排序在单线程内部可忽略。
总结
本文从两方面论述了volatile的重要性以及不可替代性：
一方面是因为synchronized是一种锁机制，存在阻塞问题和性能问题，而volatile并不是锁，所以不存在阻塞和性能问题。
另外一方面，因为volatile借助了内存屏障来帮助其解决可见性和有序性问题，而内存屏障的使用还为其带来了一个禁止指令重排的附件功能，所以在有些场景中是可以避免发生指令重排的问题的。
同步容器（如Vector）的所有操作一定是线程安全的？
http://www.hollischuang.com/archives/3935
为了方便编写出线程安全的程序，Java里面提供了一些线程安全类和并发工具，比如：同步容器、并发容器、阻塞队列等。
最常见的同步容器就是Vector和Hashtable了，那么，同步容器的所有操作都是线程安全的吗？
这个问题不知道你有没有想过，本文就来深入分析一下这个问题，一个很容易被忽略的问题。
Java中的同步容器
在Java中，同步容器主要包括2类：
1、Vector、Stack、HashTable
2、Collections类中提供的静态工厂方法创建的类
本文拿相对简单的Vecotr来举例，我们先来看下Vector中几个重要方法的源码：
public synchronized boolean add(E e) {
modCount++;
ensureCapacityHelper(elementCount + 1);
elementData[elementCount++] = e;
return true;}
public synchronized E remove(int index) {
modCount++;
if (index >= elementCount)
throw new ArrayIndexOutOfBoundsException(index);
E oldValue = elementData(index);
int numMoved = elementCount - index - 1;
if (numMoved > 0)
System.arraycopy(elementData, index+1, elementData, index,
numMoved);
elementData[--elementCount] = null; // Let gc do its work
return oldValue;}
public synchronized E get(int index) {
if (index >= elementCount)
throw new ArrayIndexOutOfBoundsException(index);
return elementData(index);}
可以看到，Vector这样的同步容器的所有公有方法全都是synchronized的，也就是说，我们可以在多线程场景中放心的使用单独这些方法，因为这些方法本身的确是线程安全的。
但是，请注意上面这句话中，有一个比较关键的词：单独
因为，虽然同步容器的所有方法都加了锁，但是对这些容器的复合操作无法保证其线程安全性。需要客户端通过主动加锁来保证。
简单举一个例子，我们定义如下删除Vector中最后一个元素方法：
public Object deleteLast(Vector v){
int lastIndex = v.size()-1;
v.remove(lastIndex);}
上面这个方法是一个复合方法，包括size(）和remove()，乍一看上去好像并没有什么问题，无论是size()方法还是remove()方法都是线程安全的，那么整个deleteLast方法应该也是线程安全的。
但是时，如果多线程调用该方法的过程中，remove方法有可能抛出ArrayIndexOutOfBoundsException。
Exception in thread “Thread-1” java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 879
at java.util.Vector.remove(Vector.java:834)
at com.hollis.Test.deleteLast(EncodeTest.java:40)
at com.hollis.Test$2.run(EncodeTest.java:28)
at java.lang.Thread.run(Thread.java:748)
我们上面贴了remove的源码，我们可以分析得出：当index >= elementCount时，会抛出ArrayIndexOutOfBoundsException ，也就是说，当当前索引值不再有效的时候，将会抛出这个异常。
因为removeLast方法，有可能被多个线程同时执行，当线程2通过index()获得索引值为10，在尝试通过remove()删除该索引位置的元素之前，线程1把该索引位置的值删除掉了，这时线程一在执行时便会抛出异常。

为了避免出现类似问题，可以尝试加锁：
public void deleteLast() {
synchronized (v) {
int index = v.size() - 1;
v.remove(index);
}}
如上，我们在deleteLast中，对v进行加锁，即可保证同一时刻，不会有其他线程删除掉v中的元素。
另外，如果以下代码会被多线程执行时，也要特别注意：
for (int i = 0; i < v.size(); i++) {
v.remove(i);}
由于，不同线程在同一时间操作同一个Vector，其中包括删除操作，那么就同样有可能发生线程安全问题。所以，在使用同步容器的时候，如果涉及到多个线程同时执行删除操作，就要考虑下是否需要加锁。
同步容器的问题
前面说过了，同步容器直接保证耽搁操作的线程安全性，但是无法保证复合操作的线程安全，遇到这种情况时，必须要通过主动加锁的方式来实现。
而且，除此之外，同步容易由于对其所有方法都加了锁，这就导致多个线程访问同一个容器的时候，只能进行顺序访问，即使是不同的操作，也要排队，如get和add要排队执行。这就大大的降低了容器的并发能力。
并发容器
针对前文提到的同步容器存在的并发度低问题，从Java5开始，java.util.concurent包下，提供了大量支持高效并发的访问的集合类，我们称之为并发容器。

针对前文提到的同步容器的复合操作的问题，一般在Map中发生的比较多，所以在ConcurrentHashMap中增加了对常用复合操作的支持，比如”若没有则添加”：putIfAbsent()，替换：replace()。这2个操作都是原子操作，可以保证线程安全。
另外，并发包中的CopyOnWriteArrayList和CopyOnWriteArraySet是Copy-On-Write的两种实现。
Copy-On-Write容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。
CopyOnWriteArrayList中add/remove等写方法是需要加锁的，而读方法是没有加锁的。
这样做的好处是我们可以对CopyOnWrite容器进行并发的读，当然，这里读到的数据可能不是最新的。因为写时复制的思想是通过延时更新的策略来实现数据的最终一致性的，并非强一致性。
但是，作为代替Vector的CopyOnWriteArrayList并没有解决同步容器的复合操作的线程安全性问题。
总结
本文介绍了同步容器和并发容器。
同步容器是通过加锁实现线程安全的，并且只能保证单独的操作是线程安全的，无法保证复合操作的线程安全性。并且同步容器的读和写操作之间会互相阻塞。
并发容器是Java 5中提供的，主要用来代替同步容器。有更好的并发能力。而且其中的ConcurrentHashMap定义了线程安全的复合操作。
在多线程场景中，如果使用并发容器，一定要注意复合操作的线程安全问题。必要时候要主动加锁。
在并发场景中，建议直接使用java.util.concurent包中提供的容器类，如果需要复合操作时，建议使用有些容器自身提供的复合方法。
锁分类
可中断锁：
在等待获取锁过程中可中断。synchronized就不是可中断锁，而Lock是可中断锁。
读写锁
对资源读取和写入的时候拆分为2部分处理，一个读锁和一个写锁。读的时候可以多线程一起读，写的时候必须同步地写。ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。可以通过readLock()获取读锁，通过writeLock()获取写锁。
乐观锁
(冲突检测和数据更新)
很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会去判断在此期间有没有人去更新这个数据（可以使用版本号等机制）。如果因为冲突失败就重试。乐观锁适用于写比较少的情况下，即冲突比较少发生，这样可以省去了锁的开销，加大了系统的整个吞吐量。像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
乐观锁的实现方式（CAS）
乐观锁的实现主要就两个步骤：冲突检测和数据更新。其实现方式有一种比较典型的就是 Compare and Swap ( CAS )。
CAS：
CAS是乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。
CAS 操作中包含三个操作数 —— **需要读写的内存位置（V）、进行比较的预期原值（A）和拟写入的新值(B)**。 如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。（在 CAS 的一些特殊情况下将仅返回 CAS 是否成功，而不提取当前值。）CAS 有效地说明了“ 我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。 ”这其实和乐观锁的冲突检查+数据更新的原理是一样的。
乐观锁是一种思想，CAS是这种思想的一种实现方式。
CAS的缺点
- ABA问题
如果内存地址V初次读取的值是A，并且在准备赋值的时候检查到它的值仍然为A，那我们就能说它的值没有被其他线程改变过了吗？如果在这段期间它的值曾经被改成了B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的“ABA”问题。java并发包为了解决这个问题，提供了一个带有标记的原子引用类“AtomicStampedReference”，它可以通过控制变量值的版本来保证CAS的正确性。因此，在使用CAS前要考虑清楚“ABA”问题是否会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效。
循环时间长开销很大 - 自旋CAS（不成功，就一直循环执行，直到成功）
如果长时间不成功，会给CPU带来非常大的执行开销。 - 只能保证一个共享变量的原子操作。
当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁来保证原子性。
悲观锁：
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，因此每次拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁，效率比较低。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。
公平锁
是指多个线程按照申请锁的顺序来获取锁，类似排队打饭，先来后到。
非公平锁
是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。在高并发的情况下，有可能造成优先级反转或者饥饿现象。ReentrantLock默认是非公平锁，但是可以设置为true成为公平锁，Synchonized也是非公平锁。
可重入锁（递归锁）
指的是同一线程外层函数获得锁之后，内层递归函数仍然能获取该锁的代码，在同一线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。
线程可以进入任何一个它已经拥有的锁所同步着的代码块。
最大作用：避免死锁ReentrantLock和Synchonized都是可重入锁。
public class SynchronziedDemo {
private synchronized void print() {
doAdd();
}
private synchronized void doAdd() {
System.out.println(“doAdd…”);
}
public static void main(String[] args) {
SynchronziedDemo synchronziedDemo = new SynchronziedDemo();
synchronziedDemo.print(); // doAdd…
}
}
/**
注意：Lock.lock();和Lock.unlock();个数匹配，多少个锁都可以正常运行，若是不匹配，则程序运行卡死。
*/
public class ReentrantLockDemo {
private Lock lock = new ReentrantLock();
private void print() {
lock.lock();
doAdd();
lock.unlock();
}
private void doAdd() {
lock.lock();
lock.lock();
System.out.println(“doAdd…”);
lock.unlock();
lock.unlock();
}
public static void main(String[] args) {
ReentrantLockDemo reentrantLockDemo = new ReentrantLockDemo();
reentrantLockDemo.print();
}
}
自旋锁
指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。
- 手动实行自旋锁
public class SpinLock {
private AtomicReference
private void lock () {
System.out.println(Thread.currentThread() + “ coming…”);
while (!atomicReference.compareAndSet(null, Thread.currentThread())) {
// loop
}
}
private void unlock() {
Thread thread = Thread.currentThread();
atomicReference.compareAndSet(thread, null);
System.out.println(thread + “ unlock…”);
}
public static void main(String[] args) throws InterruptedException {
SpinLock spinLock = new SpinLock();
new Thread(() -> {
spinLock.lock();
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(“hahaha”);
spinLock.unlock();
}).start();
Thread.sleep(1);
new Thread(() -> {
spinLock.lock();
System.out.println("hehehe");
spinLock.unlock();
}).start();
}
}
死锁 及 如何解决
什么是死锁：两个进程都在等待对方执行完毕才能继续往下执行的时候就发生了死锁。结果就是两个进程都陷入了无限的等待中。
产生死锁的四个必要条件：
互斥条件：一个资源每次只能被一个进程使用。
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
- 考虑如下情形：
- 线程A当前持有互斥锁lock1，线程B当前持有互斥锁lock2。
- 线程A试图获取lock2，因为线程B正持有lock2，因此线程A会阻塞等待线程B对lock2释放。
- 如果此时线程B也在试图获取lock1，同理线程也会阻塞。
- 两者都在等待对方所持有但是双方都不释放的锁，这时便会一直阻塞形成死锁。
- 死锁的解决方法:
- 撤消陷于死锁的全部进程；
- 逐个撤消陷于死锁的进程，直到死锁不存在；
- 从陷于死锁的进程中逐个强迫放弃所占用的资源，直至死锁消失。
- 从另外一些进程那里强行剥夺足够数量的资源分配给死锁进程，以解除死锁状态
如何确保 N 个线程可以访问 N 个资源同时又不导致死锁？
使用多线程的时候，一种非常简单的避免死锁的方式就是：指定获取锁的顺序，并强制线程按照指定的顺序获取锁。因此，如果所有的线程都是以同样的顺序加锁和释放锁，就不会出现死锁了
乐观锁的业务场景及实现方式
说说线程安全的问题
死锁
在多道程序环境中，多个进程可以竞争有限数量的资源。当一个进程申请资源时，如果这时没有可用资源，那么这个进程进入等待状态。有时，如果所申请的资源被其他等待进程占有，那么该等待进程有可能再也无法改变状态。这种情况称为死锁。
“当两列列车在十字路口逼近时，它们应完全停下来，并且在一列列车开走之前另一列列车不能再次启动。”
死锁特征
发生死锁时，进程永远不能完成，系统资源被阻碍使用，以致于阻止了其他作业开始执行。在讨论处理死锁问题的各种方法之前，我们首先深入讨论一下死锁特点。
必要条件
如果在一个系统中以下四个条件同时成立，那么就能引起死锁：
1 互斥：至少有一个资源必须处于非共享模式，即一次只有一个进程可使用。如果另一进程申请该资源，那么申请进程应等到该资源释放为止。
2 占有并等待：—个进程应占有至少一个资源，并等待另一个资源，而该资源为其他进程所占有。
3 非抢占：资源不能被抢占，即资源只能被进程在完成任务后自愿释放。
4 循环等待：有一组等待进程 {P0，P1，…，Pn}，P0 等待的资源为 P1 占有，P1 等待的资源为 P2 占有，……，Pn-1 等待的资源为 Pn 占有，Pn 等待的资源为 P0 占有。
我们强调所有四个条件必须同时成立才会出现死锁。循环等待条件意味着占有并等待条件，这样四个条件并不完全独立。
死锁处理方法
一般来说，处理死锁问题有三种方法：
1 通过协议来预防或避免死锁，确保系统不会进入死锁状态。
2 可以允许系统进入死锁状态，然后检测它，并加以恢复。
3 可以忽视这个问题，认为死锁不可能在系统内发生。
1.撤消陷于死锁的全部进程；
2.逐个撤消陷于死锁的进程，直到死锁不存在；
3.从陷于死锁的进程中逐个强迫放弃所占用的资源，直至死锁消失。
4.从另外一些进程那里强行剥夺足够数量的资源分配给死锁进程，以解除死锁状态
如何确保 N 个线程可以访问 N 个资源同时又不导致死锁？
使用多线程的时候，一种非常简单的避免死锁的方式就是：指定获取锁的顺序，并强制线程按照指定的顺序获取锁。因此，如果所有的线程都是以同样的顺序加锁和释放锁，就不会出现死锁了
银行家算法 避免死锁
在进程提出资源申请时，先预判此分配是否会导致系统进入不安全状态。如果会进入不安全状态，就暂时不答应这次请求，让该进程先阻塞等待。
算法步骤
1、检查此次申请是否超过了之前声明的最大需求数
2、检查此时系统剩余的可用资源是否还能满足这次请求
3、试探着分配，更改数据结构
4、用安全性算法检查此次分配是否会导致系统进入不安全状态
锁的四种状态与锁升级过程
http://t.zoukankan.com/mingyueyy-p-13054296.html
无锁、偏向锁、轻量级锁、重量级锁
并且四种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，即不可降级，也就是说只能进行锁升级（从低级别到高级别），不能锁降级（高级别到低级别），意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。
在 synchronized 最初的实现方式是 “阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，这种方式就是 synchronized实现同步最初的方式，这也是当初开发者诟病的地方，这也是在JDK6以前 synchronized效率低下的原因，JDK6中为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”。
所以目前锁状态一种有四种，从级别由低到高依次是：无锁、偏向锁，轻量级锁，重量级锁，锁状态只能升级，不能降级
锁状态的思路以及特点
锁状态 存储内容 标志位
无锁 对象的hashCode、对象分代年龄、是否是偏向锁(0) 01
偏向锁 偏向线程ID、偏向时间戳、对象分代年龄、是否是偏向锁(1) 01
轻量级锁 指向栈中锁记录的指针 00
重量级锁 指向互斥量的指针 11
synchronized 用的锁是存在Java对象头里的，那么什么是对象头呢？
Java 对象头
我们以 Hotspot 虚拟机为例，Hopspot 对象头主要包括两部分数据：Mark Word（标记字段） 和 Klass Pointer（类型指针）
Mark Word：默认存储对象的HashCode，分代年龄和锁标志位信息。这些信息都是与对象自身定义无关的数据，所以Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据。它会根据对象的状态复用自己的存储空间，也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。
Klass Point：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
在上面中我们知道了，synchronized 用的锁是存在Java对象头里的，那么具体是存在对象头哪里呢？答案是：存在锁对象的对象头的Mark Word中，那么MarkWord在对象头中到底长什么样，它到底存储了什么呢？
在64位的虚拟机中：
下面我们以 32位虚拟机为例，来看一下其 Mark Word 的字节具体是如何分配的
无锁：对象头开辟 25bit 的空间用来存储对象的 hashcode ，4bit 用于存放对象分代年龄，1bit 用来存放是否偏向锁的标识位，2bit 用来存放锁标识位为01
偏向锁： 在偏向锁中划分更细，还是开辟 25bit 的空间，其中23bit 用来存放线程ID，2bit 用来存放 Epoch，4bit 存放对象分代年龄，1bit 存放是否偏向锁标识， 0表示无锁，1表示偏向锁，锁的标识位还是01
轻量级锁：在轻量级锁中直接开辟 30bit 的空间存放指向栈中锁记录的指针，2bit 存放锁的标志位，其标志位为00
重量级锁： 在重量级锁中和轻量级锁一样，30bit 的空间用来存放指向重量级锁的指针，2bit 存放锁的标识位，为11
GC标记： 开辟30bit 的内存空间却没有占用，2bit 空间存放锁标志位为11。
其中无锁和偏向锁的锁标志位都是01，只是在前面的1bit区分了这是无锁状态还是偏向锁状态
关于内存的分配，我们可以在git中openJDK中 markOop.hpp 可以看出：
public:
// Constants
enum { age_bits = 4,
lock_bits = 2,
biased_lock_bits = 1,
max_hash_bits = BitsPerWord - age_bits - lock_bits - biased_lock_bits,
hash_bits = max_hash_bits > 31 ? 31 : max_hash_bits,
cms_bits = LP64_ONLY(1) NOT_LP64(0),
epoch_bits = 2
};
age_bits： 就是我们说的分代回收的标识，占用4字节
lock_bits： 是锁的标志位，占用2个字节
biased_lock_bits： 是是否偏向锁的标识，占用1个字节
max_hash_bits： 是针对无锁计算的hashcode 占用字节数量，如果是32位虚拟机，就是 32 - 4 - 2 -1 = 25 byte，如果是64 位虚拟机，64 - 4 - 2 - 1 = 57 byte，但是会有 25 字节未使用，所以64位的 hashcode 占用 31 byte
hash_bits： 是针对 64 位虚拟机来说，如果最大字节数大于 31，则取31，否则取真实的字节数
cms_bits： 不是64位虚拟机就占用 0 byte，是64位就占用 1byte
epoch_bits： 就是 epoch 所占用的字节大小，2字节。
Monitor
Monitor 可以理解为一个同步工具或一种同步机制，通常被描述为一个对象。每一个 Java 对象就有一把看不见的锁，称为内部锁或者 Monitor 锁。
Monitor 是线程私有的数据结构，每一个线程都有一个可用 monitor record 列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个 monitor 关联，同时 monitor 中有一个 Owner 字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。
Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的，监视器锁本质又是依赖于底层的操作系统的 Mutex Lock（互斥锁）来实现的。而操作系统实现线程之间的切换需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么 Synchronized 效率低的原因。因此，这种依赖于操作系统 Mutex Lock 所实现的锁我们称之为重量级锁。
随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。JDK 1.6中默认是开启偏向锁和轻量级锁的，我们也可以通过-XX:-UseBiasedLocking=false来禁用偏向锁。
6.2 无锁
无锁是指没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。
无锁的特点是修改操作会在循环内进行，线程会不断的尝试修改共享资源。如果没有冲突就修改成功并退出，否则就会继续循环尝试。如果有多个线程修改同一个值，必定会有一个线程能修改成功，而其他修改失败的线程会不断重试直到修改成功。
6.3 偏向锁
初次执行到synchronized代码块的时候，锁对象变成偏向锁（通过CAS修改对象头里的锁标志位），字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。当第二次到达同步代码块时，线程会判断此时持有锁的线程是否就是自己（持有锁的线程ID也在对象头里），如果是则正常往下执行。由于之前没有释放锁，这里也就不需要重新加锁。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
偏向锁是指当一段同步代码一直被同一个线程所访问时，即不存在多个线程的竞争时，那么该线程在后续访问时便会自动获得锁，从而降低获取锁带来的消耗，即提高性能。
当一个线程访问同步代码块并获取锁时，会在 Mark Word 里存储锁偏向的线程 ID。在线程进入和退出同步块时不再通过 CAS 操作来加锁和解锁，而是检测 Mark Word 里是否存储着指向当前线程的偏向锁。轻量级锁的获取及释放依赖多次 CAS 原子指令，而偏向锁只需要在置换 ThreadID 的时候依赖一次 CAS 原子指令即可。
偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。
关于偏向锁的撤销，需要等待全局安全点，即在某个时间点上没有字节码正在执行时，它会先暂停拥有偏向锁的线程，然后判断锁对象是否处于被锁定状态。如果线程不处于活动状态，则将对象头设置成无锁状态，并撤销偏向锁，恢复到无锁（标志位为01）或轻量级锁（标志位为00）的状态。
6.4 轻量级锁（自旋锁）
轻量级锁是指当锁是偏向锁的时候，却被另外的线程所访问，此时偏向锁就会升级为轻量级锁，其他线程会通过自旋（关于自旋的介绍见文末）的形式尝试获取锁，线程不会阻塞，从而提高性能。
轻量级锁的获取主要由两种情况：
① 当关闭偏向锁功能时；
② 由于多个线程竞争偏向锁导致偏向锁升级为轻量级锁。
一旦有第二个线程加入锁竞争，偏向锁就升级为轻量级锁（自旋锁）。这里要明确一下什么是锁竞争：如果多个线程轮流获取一个锁，但是每次获取锁的时候都很顺利，没有发生阻塞，那么就不存在锁竞争。只有当某线程尝试获取锁的时候，发现该锁已经被占用，只能等待其释放，这才发生了锁竞争。
在轻量级锁状态下继续锁竞争，没有抢到锁的线程将自旋，即不停地循环判断锁是否能够被成功获取。获取锁的操作，其实就是通过CAS修改对象头里的锁标志位。先比较当前锁标志位是否为“释放”，如果是则将其设置为“锁定”，比较并设置是原子性发生的。这就算抢到锁了，然后线程将当前锁的持有者信息修改为自己。
长时间的自旋操作是非常消耗资源的，一个线程持有锁，其他线程就只能在原地空耗CPU，执行不了任何有效的任务，这种现象叫做忙等（busy-waiting）。如果多个线程用一个锁，但是没有发生锁竞争，或者发生了很轻微的锁竞争，那么synchronized就用轻量级锁，允许短时间的忙等现象。这是一种折衷的想法，短时间的忙等，换取线程在用户态和内核态之间切换的开销。
6.4 重量级锁
重量级锁显然，此忙等是有限度的（有个计数器记录自旋次数，默认允许循环10次，可以通过虚拟机参数更改）。如果锁竞争情况严重，某个达到最大自旋次数的线程，会将轻量级锁升级为重量级锁（依然是CAS修改锁标志位，但不修改持有锁的线程ID）。当后续线程尝试获取锁时，发现被占用的锁是重量级锁，则直接将自己挂起（而不是忙等），等待将来被唤醒。
重量级锁是指当有一个线程获取锁之后，其余所有等待获取该锁的线程都会处于阻塞状态。
简言之，就是所有的控制权都交给了操作系统，由操作系统来负责线程间的调度和线程的状态变更。而这样会出现频繁地对线程运行状态的切换，线程的挂起和唤醒，从而消耗大量的系统资
AQS（抽象队列同步器）
先上一张类图，便于了解ReentrantLock、AQS之间的关系，这样对于他们之间的相互调用的关系更清楚：
可以看到，ReentrantLock类中有三个内部类：Sync、FairSync（公平锁）和NonfairSync（非公平锁），Sync都是AQS的子类，FairSync和NonfairSync是Sync的子类；AQS中有一个静态内部类Node，Node相当于一个节点，用于构建同步队列用的，这个下面会讲到
ReentranLock
【1】什么是可重入，什么是可重入锁? 它用来解决什么问题?
【2】ReentrantLock 的核心是 AQS，那么它怎么来实现的，继承吗? 说说其类内部结构关系。
【3】ReentrantLock 是如何实现公平锁的?
【4】ReentrantLock 是如何实现非公平锁的?
【5】ReentrantLock 默认实现的是公平还是非公平锁?
【6】使用ReentrantLock 实现公平和非公平锁的示例?
【7】ReentrantLock 和 Synchronized的对比?
25.redis 分布式锁
分布式锁-Redis
实现基础
首先Redis是单线程的，这里的单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。而且Redis的性能很好，即使在多个服务争抢锁的时候也能够从容处理众多请求。
方案1
加锁命令 SET [KEY] [VALUE] NX
解锁命令 DEL [KEY]
这是最基础的使用方式，加锁时因为存在NX关键词，所以只有当该KEY不存在的才能成功加锁。解锁时直接删除即可。
这种方式也需单机Demo中能够正常运行，但是在分布式环境中就会产生其他问题。
如果某项业务在加锁后程序未执行解锁便退出了，这种情况下，将会造成死锁的情况 ，该位置的锁会永远不能解锁。
方案2
基于上面的弊端与缺陷，我们改进加锁命令就有：
加锁命令 SET [KEY] [VALUE] NX PX 30000
解锁命令 DEL [KEY]
在加锁命令中，同时为该锁设置一个过期时间，可以一定程度上避免方案1中出现的死锁情况。
现方案会有两个问题：
解锁指令不够健壮，可能会导致误解锁的情况。
如果加锁者与解锁者不是同一个，业务可能会导致许多问题。
过期时间可能会与业务运行情况强行相关，且影响性能。
过期时间设置得过短，可能在业务没运行完的时候就解锁了；过期时间设置过长，在加锁者宕机的情况下，其他服务器等待时间过长，影响性能。
方案3 #
加锁命令SET [KEY] [VALUE] NX PX 30000
解锁命令
if redis.call (“get”,KEYS[1]) == ARGV[1] then
return redis.call(“del”,KEYS[1])
else
return 0
End
修改：
1.设置保护线程在加锁成功后不断的更新过期时间。
2. 解锁命令由Lua脚本替代。由于解锁命令需要进行两次Redis操作，第一步为判断该KEY的VALUE和输入的VALUE是否一致，是的情况下进行第二步，删除该KEY，Redis中可以保证每一条命令是原子性的，但是连续两条命令是并不能保证，因此使用Lua脚本可以将两条命令合二为一，使解锁命令为原子操作。
Redisson - WatchDog
Redisson中已经实现的WatchDog机制，也就是方案三种的守护线程的工作。
大家都知道，如果负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。
Redisson中的WatchDog机制是一种无限递归调用的方式，该方法的定义为：
updateExpireTime(){
async{
sleep(5000);
setExpireTime();
updateExpireTime();
}
}
该方法通过异步调用形式，能够以每5min的频率更新Expire值
Redis的部署模式有3种：
单机部署
Master-Slave
集群
不论是方案3还是方案4，在单机中能够正常运行，但是并不能达到高可用性的要求。如果是主从模式，如果发生在Master节点加锁后，锁信息还未通知到Slave节点的情况下，锁信息会丢失，所以在高可用上仍然有一些问题，因此Redis的作者提出了RedLock算法来解决该问题。
RedLock
antirez提出的redlock算法大概是这样的：
在Redis的分布式环境中，我们假设有N个Redis master。这些节点完全互相独立，不存在主从复制或者其他集群协调机制。我们确保将在N个实例上使用与在Redis单实例下相同方法获取和释放锁。现在我们假设有5个Redis master节点，同时我们需要在5台服务器上面运行这些Redis实例，这样保证他们不会同时都宕掉。
为了取到锁，客户端应该执行以下操作:
· 获取当前Unix时间，以毫秒为单位。
· 依次尝试从5个实例，使用相同的key和具有唯一性的value（例如UUID）获取锁。当向Redis请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试去另外一个Redis实例请求获取锁。
· 客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间。当且仅当从大多数（N/2+1，这里是3个节点）的Redis节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。
· 如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）。
· 如果因为某些原因，获取锁失败（没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁（即便某些Redis实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁）。
zookeeper分布式锁
分布式锁-ZooKeeper
ZooKeeper可以创建4种类型的节点 #
持久性节点 PERSISTENT
持久性顺序节点 PERSISTENT_SEQUENTIAL
临时性节点 EPHEMERAL
临时性顺序节点 EPHEMERAL_SEQUENTIAL
持久性节点和临时性节点的区别：
持久性节点表示只要你创建了这个节点，那不管你ZooKeeper的客户端是否断开连接，ZooKeeper的服务端都会记录这个节点；
临时性节点刚好相反，一旦你ZooKeeper客户端断开了连接，那ZooKeeper服务端就不再保存这个节点；
顺序性节点是指，在创建节点的时候，ZooKeeper会自动给节点编号比如0000001，0000002这种的。
优化
Zookeeper有一个监听机制，客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）等，Zookeeper将会通知客户端。
假设server-1，创建了一个节点 /lock，成功了，那server-1就获取了锁，server-2再去创建相同的锁，就会失败，这个时候就只能监听这个节点的变化。
等到server-1处理完业务，删除节点，释放锁后，server-2就会得到通知，然后去创建同样的节点，获取锁后开始处理业务，再删除节点释放锁，后续的100台服务器与之类似。
注意：这里的100台服务器并不是逐个执行上面的创建节点的操作，而是并发的，当服务器1创建成功，那么剩下的99个就都会同时注册监听这个节点，等通知，以此类推。
这个时候就需要用到临时性节点了，前文提到，临时性节点的特点是客户端一旦断开，就会丢失，也就是当server-1创建了节点后，如果服务挂了，则该节点会自动被删除，这样后续的其他服务器，就可以继续去创建节点，获取锁了。
另外我们还需注意的是惊群效应：举一个很简单的例子，当你往一群鸽子中间扔一块食物，虽然最终只有一个鸽子抢到食物，但所有鸽子都会被惊动来争夺，没有抢到…
也就是说当server-1节点有变化，会通知其余的99个服务器，但是最终只有1个服务器会创建成功，这样98还是需要等待监听，那么为了处理这种情况，就需要用到临时顺序性节点。大致意思就是，之前是所有99个服务器都监听一个节点，现在就是每一个服务器监听自己前面的一个节点。
假设100个服务器同时发来请求，这个时候会在/lock节点下创建100个临时顺序性节点/lock/001，/lock/002，一直到/lock/100，这个编号就等于是已经给他们设置了获取锁的先后顺序了。
一般实现
利用ZooKeeper的临时性节点，构建分布式锁。
服务通过请求创建锁节点，成功则代表加锁成功，失败则代表加锁。基于临时性节点的定义，当服务离线时，由该服务创建的节点将自动删除，则完成离线自动解锁操作。
Curator实现
InterProcessMutex 分布式可重入排它锁
InterProcessMutex lock = new InterProcessMutex(client, LOCK_PATH);
lock.acquire();
lock.release();
InterProcessSemaphoreMutex 分布式排它锁
InterProcessSemaphoreMutex是一种不可重入的互斥锁，也就意味着即使是同一个线程也无法在持有锁的情况下再次获得锁，所以需要注意，不可重入的锁很容易在一些情况导致死锁。
InterProcessSemaphoreMutex lock = new InterProcessSemaphoreMutex(zkClient, LOCK_PATH);
lock.acquire();
lock.release();
InterProcessReadWriteLock 分布式读写锁
读锁和读锁不互斥，只要有写锁就互斥。
InterProcessReadWriteLock lock = new InterProcessReadWriteLock(zkClient, LOCK_PATH);
lock.readLock().acquire();
lock.readLock().release();
lock.writeLock().acquire();
lock.writeLock().release();
InterProcessMultiLock 将多个锁作为单个实体管理的容器
InterProcessMutex lock1 = new InterProcessMutex(zkClient, LOCK_PATH + “1”);
InterProcessMutex lock2 = new InterProcessMutex(zkClient, LOCK_PATH + “2”);
InterProcessMultiLock lock = new InterProcessMultiLock(Arrays.asList(lock1, lock2));
lock.acquire();
lock.release();