简单介绍一下Synchronized 关键字的一些理解
synchronized关键字最主要的三种使用方式的总结：
1.修饰实例方法：作用于当前对象实例加锁，进入同步代码前要获得当前对象的锁。
2.修饰静态方法：作用于当前类对象加锁，进入同步代码前需要获取当前类对象的锁。也就是给当前类加锁，会作用于类的所有实例对象，因为静态成员不属于任何一个实例对象，是类成员（static表明这是一个该类的一个静态资源，不管new了多少个对象，但是这个静态成员变量只有一份，所以对该类的所有对象都加了锁）。所以如果一个线程A调用一个实例对象的非静态synchronized方法，而线程B需要调用这个实例对象所属类的静态synchronized方法，是允许的，不会发生互斥现象，因为访问非静态synchronized方法占用的锁是当前实例对象，访问静态synchronized是占用的是当前类对象的，相当于给Class上锁。
3.修饰代码块：指定加锁对象，对给定对象加锁，进入同步代码块前要获得给定对象的锁。和synchronized方法一样，这里需要注意的是：synchronized（this）也是锁定当前实例对象的。给static静态方法加锁和synchronized（Class）是其实就是锁定的当前类对象，需要注意，synchronized锁定非static方法和synchronized（this）是给对象实例进行上锁。另外 尽量不要使用synchronized（String a）因为JVM中，字符串常量池也具有缓冲功能。
讲解synchronized关键字
单例模式了解吗？解释一下双重检验方式实现单例模式的原理？
public class Singleton { private volatile static Singleton uniqueInstance; private Singleton() { } public static Singleton getUniqueInstance() { //先判断对象是否已经实例过，没有实例化过才进入加锁代码 if (uniqueInstance == null) { //类对象加锁 synchronized (Singleton.class) { if (uniqueInstance == null) { uniqueInstance = new Singleton(); } } } return uniqueInstance; } }
另外，需要注意的是uniqueInstance采用volatile关键字也是很有必要。
uniqueInstance采用volatile关键修饰是很有必要的，uniqueInstance=new Singleton()；主要是分为三步执行：
1.为uniqueInstance分配内存空间
2.初始化uniqueInstance
3.将uniqueInstance指向分配的内存地址
但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。
使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。
synchronized关键字底层原理总结：
synchronized 关键字底层原理属于 JVM 层面。
① synchronized 同步语句块的情况
public class SynchronizedDemo {
public void method() {
synchronized (this) {
System.out.println("synchronized 代码块");
}
}
}通过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息：首先切换到类的对应目录执行 javac SynchronizedDemo.java 命令生成编译后的 .class 文件，然后执行javap -c -s -v -l SynchronizedDemo.class。
从上面我们可以看出：
synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。 当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每个Java对象的对象头中，synchronized 锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因) 的持有权.当计数器为0则可以成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。
② synchronized 修饰方法的的情况
public class SynchronizedDemo2 {
public synchronized void method() {
System.out.println("synchronized 方法");
}
}
synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。
在 Java 早期版本中，synchronized 属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
JDK1.6之后的底层优化
自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
锁主要存在四种状态：无锁，偏向锁，轻量级锁，重量级锁状态，我们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。
1.偏向锁：
引入偏向锁的目的和引入轻量级锁的目的很像，他们都是为了没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗，但是不同的是：轻量级锁在无竞争的情况下，使用CAS操作去代替使用互斥量。而偏向锁在无竞争的情况下会把整个同步都消除掉。
偏向锁的“偏"其实就是偏心的意思，它的意识会偏向于第一个获得它的线程，如果在接下来的执行中，该锁没有被其他线程获取，那么持有偏向锁的线程就不会需要同步！偏向锁的原理查看深入理解java虚拟机的第13章第三节锁优化。
但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样的场合极有可能每次都申请锁的线程都是不同的，因为这种场合不不应该再使用偏向锁了，否则会得不偿失，需要注意的是，在获取偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。
2.轻量级锁：
偏向锁获取失败，虚拟机并不会直接转换为重量级锁，还会尝试使用一种称为轻量级锁的优化手段（1.6之后加入的），轻量级锁不是为了代替重量级锁而产生的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗产生的，因为使用轻量级锁的时候，不需要申请互斥量。另外，轻量级锁的加锁和解锁都用到了CAS操作。关于轻量级锁的加锁和解锁的原理具体和查看《深入理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。
轻量级锁能够提升程序同步性能的依据是“对于绝大部分锁，在整个同步周期内都是不存在竞争的“,这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量操作的开销。如果存在锁竞争，除了互斥量开销外，还会额外发生CAS操作，因为在有所竞争的情况下，轻量级锁比传统的重量级锁更慢，如果锁竞争激烈，会很快升级到重量级锁。
3.自旋锁和自适应自旋
轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。
互斥同步对性能最大的影响就是阻塞的实现，因为挂起线程/恢复线程的操作都需要转入内核态中完成（用户态转换到内核态会耗费时间）。
一般线程持有锁的时间都不是太长，所以仅仅为了这一点时间去挂起线程/恢复线程是得不偿失的。 所以，虚拟机的开发团队就这样去考虑：“我们能不能让后面来的请求获取锁的线程等待一会而不被挂起呢？看看持有锁的线程是否很快就会释放锁”。为了让一个线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就叫做自旋。
百度百科对自旋锁的解释：
何谓自旋锁？它是为实现保护共享资源而提出一种锁机制。 其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。 无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说， 在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。 对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。 但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持， 调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。
自旋锁在 JDK1.6 之前其实就已经引入了，不过是默认关闭的，需要通过--XX:+UseSpinning参数来开启。JDK1.6及1.6之后，就改为默认开启的了。需要注意的是：自旋等待不能完全替代阻塞，因为它还是要占用处理器时间。如果锁被占用的时间短，那么效果当然就很好了！反之，相反！自旋等待的时间必须要有限度。如果自旋超过了限定次数任然没有获得锁，就应该挂起线程。自旋次数的默认值是10次，用户可以修改--XX:PreBlockSpin来更改。
另外,在 JDK1.6 中引入了自适应的自旋锁。自适应的自旋锁带来的改进就是：自旋的时间不在固定了，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定，虚拟机变得越来越“聪明”了。
4.锁消除
锁消除理解起来很简单，它指的就是虚拟机即使编译器在运行时，如果检测到那些共享数据不可能存在竞争，那么就执行锁消除。锁消除可以节省毫无意义的请求锁的时间。
5. 锁粗化
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小，——直在共享数据的实际作用域才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待线程也能尽快拿到锁。
大部分情况下，上面的原则都是没有问题的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，那么会带来很多不必要的性能消耗。