JDK1.6 synchronized （底层是由C++实现的）：
synchronized: 互斥锁，悲观 锁，同步锁，重量级锁（耗性能），多线程使用重量级锁很容易发生线程阻塞，因为涉及到多个线程的启动和运行；
在线程执行具体某个方法时，其他会通过synchronized实现机制丢到任务队列，等执行线程释放锁，其他线程根据抢占获得锁，在抢占的过程中，根据上下文的切换操作系统的的调度，就会发生线程的阻塞
说明一点：JDK1.6就开始对synchronized 做了大量的优化。
通过实践对比（原子类和synchronized的性能）
原子类比synchronized锁 n++ 自增的效率更快。
原子类的底层实现是不断通过while循环进行cas，直到value设置成功，在while的这一步可能会发生死循环。
CAS（compareAndset，compareAndSwapInt），自选会成为CAS的瓶颈
cas:无锁，自旋锁，乐观锁，轻量级锁，乐观锁一般情况下，是不易发生线程阻塞的，轻量级则性能更好。
原子性问题
一般使用JDK类库的包如果自带原子性，则无线程安全问题，否则就会有原子性问题。
原子性问题：
1，compare和set之间如果不是一个原子操作，就会出现多线程并发问题
（compareAndSwapInt是C语言实现的：通过JNIENV调用C++的代码，不同的JNIENV调用的C++的代码都是彼此独立的，针对不同的CPU和硬件设备，底层对应的实现机制是不一样的，C++那块的代码也是Atomic事务修饰）
特别说明：JVM跨平台就是通过Java语言帮我们做了一层屏蔽（例如native修饰的），直接调到了C++的代码，另外根据机器的不同，JVM是由不同的实现方式的。
大致流程如下
Java应用层业务代码 --> Cas --> JNI进行不同的实现机制调用到不同的C++代码 -->
汇编语言 --> asm类：会获取系统参数,判断mp属性是不是一个多核参数,如果是就返回一个Lock指令 --> 汇编指令[这里会进行操作系统级别的使用Lock指令加一把锁，让使用的类保持一个原子特性]
从流程可以看到我们的终端是通过汇编指令上Lock锁来保证变量的原子性
ABA问题 (不知道是那个线程该的数据，并将数据还原的，所以修改的内存值需要加个版本号来区分)
场景：假设线程A读到当前值是10，可能线程B把值修改为100，然后线程C又把值修改为10。
在更改值之间，原始值被其他线程修改，导致比较不能成功，从而无法进行set。
因为这种问题可以说是存在合理的，线程拿到数据，在去比较并更改，导致值发生了变更，无法set（根据业务需求看是否需要解决）
解决方式： 设置初始值时，增加一个version版本号，初始值设置为 1 ，根据版本号来分区。
AtomicStampedReferencede的底层实现，就用了这套version的实现方式
，Java也提供了AtomicStampedReference类供我们用，说白了就是加了个版本，比对的就是内存值+版本是否一致
其他方面
1，JVM默认是不开启偏向锁的，可以通过启动参数开启偏向锁
2，Thread.Sleep（不会释放锁，会持有锁，所以容易造成其他线程竞争）
3，如果有两个或两个以上的线程操作同一个变量，并且用synchronized来保证变量的线程安全问题，可以考虑使用JDK并发包的原子类 AtomicStampedReferencede和LongAdder来提升性能，因为前者由于竞争关系，会导致线程持有锁的状态升级成重量级锁，后者是轻量级锁
4，顺便提一句 LongAdder的性能 通过实践得出比 AtomicStampedReferencede的性能好
LongAdder的实现流程(CAS的瓶颈就是自旋,LongAdder的思想就是把要操作的目标资源「分散」到数组Cell中,每个线程对自己的 Cell 变量的 value 进行原子操作，大大降低了失败的次数)：
分段cas --> 分段cas++ --> 创建一个变量的副本数组 --> 其他线程对副本数组中的具体变量进行分段cas操作（造成少量的线程访问,不会触发多线程等待发生自选） --> 副本的数进行sum()在 加 1
AtomicStampedReferencede的实现流程：
CAS --> JNI --> C++ --> 汇编指令 --> 乐观锁
5,LongAdder和AtomicStampedReferencede相比，在实现流程上LongAdder多了一个分段cas借此来提高了性能
