面试套路问题总结31.Java中Synchronized的用法 synchronized修饰符的使用场景整理总结、分类

1.Java中Synchronized的用法

synchronized修饰符的使用场景整理总结、分类

一、修饰一个代码块

修饰的结果：

一个线程访问一个对象中的synchronized(this)同步代码块时，其他试图访问该对象的线程将被阻塞；
多个线程访问各子的对象即使有synchronized修饰了同步代码块，但是互不阻塞，但是并不能保证静态变量的线程安全性。
当一个线程访问对象的一个synchronized(this)同步代码块时，另一个线程仍然可以访问该对象中的非synchronized(this)同步代码块。

1.synchronized修饰的方法使用：

	/**
	 * 同步线程
	 */
	class SyncThread implements Runnable {
   		private static int count;
   		public SyncThread() {
      	count = 0;
   	}
 
   	public  void run() {
      synchronized(this) {
         for (int i = 0; i < 5; i++) {
            try {
               System.out.println(Thread.currentThread().getName() + ":" + (count++));
               Thread.sleep(100);
            } catch (InterruptedException e) {
               e.printStackTrace();
            }
         }
      }
   	}
 
   	public int getCount() {
      return count;
   		}
	}

2.验证调用代码（创建俩线程，调用一个对象）

public class codeBlock {
    	public static void main(String[] args) {
        	SyncThread syncThread = new SyncThread();
        	Thread thread1 = new Thread(syncThread, "SyncThread1");
        	Thread thread2 = new Thread(syncThread, "SyncThread2");
        	thread1.start();
        	thread2.start();
    	}
	}

3.控制台输出

SyncThread2:count:0
SyncThread2:count:1
SyncThread2:count:2
SyncThread2:count:3
SyncThread2:count:4
SyncThread2:count:5
SyncThread2:count:6
SyncThread2:count:7
SyncThread2:count:8
SyncThread2:count:9
SyncThread1:count:10
SyncThread1:count:11
SyncThread1:count:12
SyncThread1:count:13
SyncThread1:count:14
SyncThread1:count:15
SyncThread1:count:16
SyncThread1:count:17
SyncThread1:count:18
SyncThread1:count:19

4.修改代码块为俩对象（创建俩线程，分别对应俩对象）：

public class codeBlock {
    public static void main(String[] args) {
        Thread thread1 = new Thread(new SyncThread(), "SyncThread1");
        Thread thread2 = new Thread(new SyncThread(), "SyncThread2");
        thread1.start();
        thread2.start();
   		 }
	}

5.控制台输出（没有保证到线程安全性，主要由于count是静态变量）

SyncThread1:count:0
SyncThread2:count:1
SyncThread1:count:2
SyncThread2:count:2
SyncThread2:count:3
SyncThread1:count:4
SyncThread2:count:6
SyncThread1:count:5
SyncThread2:count:7
SyncThread1:count:8
SyncThread1:count:10
SyncThread2:count:9
SyncThread2:count:11
SyncThread1:count:12
SyncThread1:count:13
SyncThread2:count:14
SyncThread1:count:15
SyncThread2:count:15
SyncThread1:count:16
SyncThread2:count:16

二、修饰一个代码块（非this，而是指定对象）

修饰的结果（同synchronized(this)）：

一个线程访问一个对象中的synchronized(this)同步代码块时，其他试图访问该对象的线程将被阻塞；
多个线程访问各子的对象即使有synchronized修饰了同步代码块，但是互不阻塞，但是并不能保证静态变量的线程安全性；
当一个线程访问对象的一个synchronized(this)同步代码块时，另一个线程仍然可以访问该对象中的非synchronized(this)同步代码块。

代码块：

1.synchronized修饰的方法使用：

/**
	 * 同步线程
	 */
	class Food implements Runnable {
    public Food(Vegetables vegetables,Fruits fruits) {
        this.vegetables =vegetables;
        this.fruits=fruits;
    }
    private Vegetables vegetables;
    private Fruits fruits;
 
    @Override
    public void run() {
        synchronized (vegetables) {
            for (int i = 0; i < 10; i++) {
                vegetables.addVegetables("cabbage" + i);
                System.out.println(Thread.currentThread().getName() + ":" + vegetables.getLastVegetables());
 
            }
        }
 
        synchronized (fruits) {
            for (int i = 0; i < 10; i++) {
                fruits.addFruits("apple" + i);
                System.out.println(Thread.currentThread().getName() + ":" + fruits.getLastFruits());
            	}
        	}
 
    	}
	}
 
	class Fruits {
    	private String[] list = new String[10];
    	int index;
 
    	public Fruits() {
    	}
 
    	public void addFruits(String fruitname) {
        	if (index >= 0 && index <= 9) {
            	list[index++] = fruitname;
        	}
    	}
 
    	public String getLastFruits() {
        	return list[index-1];
    	}
	}
 
	class Vegetables {
    	private String[] list = new String[10];
    	int index;
 
    	public Vegetables() {
    	}
 
    	public void addVegetables(String Vegetablename) {
        	if (index >= 0 && index <= 9) {
            	list[index++] = Vegetablename;
        	}
    }
 
    	public String getLastVegetables() {
        	return list[index-1];
    	}
	}

2.验证调用代码（创建俩线程，调用一个对象）

public class codeBlock04 {
    	public static void main(String[] args) {
        	Food food = new Food(new Vegetables(),new Fruits());
	        Thread thread1 = new Thread(food,"Thread1");
        	Thread thread2 = new Thread(food,"Thread2");
        	thread1.start();
        	thread2.start();
	}
	}

3.控制台输出

Thread2:cabbage0
Thread2:cabbage1
Thread2:cabbage2
Thread2:cabbage3
Thread2:cabbage4
Thread2:cabbage5
Thread2:cabbage6
Thread2:cabbage7
Thread2:cabbage8
Thread2:cabbage9
Thread1:cabbage9
Thread2:apple0
Thread1:cabbage9
Thread2:apple1
Thread1:cabbage9
Thread2:apple2
Thread1:cabbage9
Thread2:apple3
Thread1:cabbage9
Thread2:apple4
Thread2:apple5
Thread1:cabbage9
Thread2:apple6
Thread1:cabbage9
Thread2:apple7
Thread2:apple8
Thread1:cabbage9
Thread1:cabbage9
Thread1:cabbage9
Thread2:apple9
Thread1:apple9
Thread1:apple9
Thread1:apple9
Thread1:apple9
Thread1:apple9
Thread1:apple9
Thread1:apple9
Thread1:apple9
Thread1:apple9
Thread1:apple9

可以看到对于fruit和vegetable对象而言各自是线程安全的，保证了各自在线程1、2中都是从1递增到9的,另一方面，synchronized控制的分别fruit和vegetable对象的同步，而food对象是可以同时被线程1、2访问并且不互相阻塞。index超过9之后无法加入内置数组。

三、修饰一个代码块

Synchronized修饰一个方法很简单，就是在方法的前面加synchronized，public synchronized void method(){//todo}; synchronized修饰方法和修饰一个代码块类似，只是作用范围不一样，修饰代码块是大括号括起来的范围，而修饰方法范围是整个函数。

代码块：

1.synchronized修饰一个方法：

public synchronized void run() {
   for (int i = 0; i < 5; i ++) {
      try {
         System.out.println(Thread.currentThread().getName() + ":" + (count++));
         Thread.sleep(100);
      } catch (InterruptedException e) {
         e.printStackTrace();
      }
   }
}

2. synchronized关键字不能继承

synchronized修饰方法的注意事项

synchronized修饰接口的定义方法；
构造方法不能使用synchronized关键字，但可以synchronized来进行对象的初始化。（解释：由于锁即对象，构造函数用于创建对象，无对象何来锁，锁的安全性也不用顾及）；
synchronized方法不能继承其synchronized关键字。

四、修饰一个修饰一个静态的方法

Synchronized也可修饰一个静态方法，用法如下：

public synchronized static void method() {
   // todo
}

我们知道静态方法是属于类的而不属于对象的。同样的，synchronized修饰的静态方法锁定的是这个类的所有对象。我们对Demo1进行一些修改如下：

1.synchronized修饰静态方法

/**
 * 同步线程
 */
class SyncThread implements Runnable {
   private static int count;
 
   public SyncThread() {
      count = 0;
   }
 
   public synchronized static void method() {
      for (int i = 0; i < 5; i ++) {
         try {
            System.out.println(Thread.currentThread().getName() + ":" + (count++));
            Thread.sleep(100);
         } catch (InterruptedException e) {
            e.printStackTrace();
         }
      }
   }
 
   public synchronized void run() {
      method();
   }
}

2.调用main方法:

SyncThread syncThread1 = new SyncThread();
SyncThread syncThread2 = new SyncThread();
Thread thread1 = new Thread(syncThread1, "SyncThread1");
Thread thread2 = new Thread(syncThread2, "SyncThread2");
thread1.start();
thread2.start();

3.控制台输出：

SyncThread2:0
SyncThread2:1
SyncThread2:2
SyncThread2:3
SyncThread2:4
SyncThread1:5
SyncThread1:6
SyncThread1:7
SyncThread1:8
SyncThread1:9

4.分析：

可以看到在对静态方法使用synchronized修饰之后，即使线程1、2调用俩个不同对象，但还是相互有阻塞，仍然保持了线程的同步。这是因为run中调用了静态方法method，而静态方法是属于类的，所以syncThread1和syncThread2相当于用了同一把锁。

五、修饰一个类

Synchronized还可作用于一个类，用法如下：

class ClassName {
   public void method() {
      synchronized(ClassName.class) {
         // todo
      }
   }
}

1.synchronized修饰类

class SyncThread3 implements Runnable {
    private static int count;
 
    public SyncThread3() {
        count = 0;
    }
 
    public static void method() {
        synchronized(SyncThread.class) {
            for (int i = 0; i < 5; i ++) {
                try {
                    System.out.println(Thread.currentThread().getName() + ":" + (count++));
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
 
    public synchronized void run() {
        method();
    }
}

其效果和synchronized修饰一个静态方法所达到的效果是一样的，synchronized作用于一个类T时，是给这个类T加锁，T的所有对象用的是同一把锁。

1.2 synchronized底层原理是什么？

synchronized有两种形式上锁，一个是对方法上锁，一个是构造同步代码块。他们的底层实现其实都一样，在进入同步代码之前先获取锁，获取到锁之后锁的计数器+1，同步代码执行完锁的计数器-1，如果获取失败就阻塞式等待锁的释放。只是他们在同步块识别方式上有所不一样，从class字节码文件可以表现出来，一个是通过方法flags标志，一个是monitorenter和monitorexit指令操作。

1.2.1 同步方法

首先来看在方法上上锁，我们就新定义一个同步方法然后进行反编译，查看其字节码：

可以看到在add方法的flags里面多了一个ACC_SYNCHRONIZED标志，这标志用来告诉JVM这是一个同步方法，在进入该方法之前先获取相应的锁，锁的计数器加1，方法结束后计数器-1，如果获取失败就阻塞住，知道该锁被释放。

1.2.1 同步代码块

我们新定义一个同步代码块，编译出class字节码，然后找到method方法所在的指令块，可以清楚的看到其实现上锁和释放锁的过程，截图如下：

从反编译的同步代码块可以看到同步块是由monitorenter指令进入，然后monitorexit释放锁，在执行monitorenter之前需要尝试获取锁，如果这个对象没有被锁定，或者当前线程已经拥有了这个对象的锁，那么就把锁的计数器加1。当执行monitorexit指令时，锁的计数器也会减1。当获取锁失败时会被阻塞，一直等待锁被释放。

但是为什么会有两个monitorexit呢？其实第二个monitorexit是来处理异常的，仔细看反编译的字节码，正常情况下第一个monitorexit之后会执行goto指令，而该指令转向的就是23行的return，也就是说正常情况下只会执行第一个monitorexit释放锁，然后返回。而如果在执行中发生了异常，第二个monitorexit就起作用了，它是由编译器自动生成的，在发生异常时处理异常然后释放掉锁。

synchronized锁的底层实现

要想理清synchronized的锁的原理，需要掌握两个重要的概念：

对象头
monitor

在理解锁实现原理之前先了解一下Java的对象头和Monitor，在JVM中，对象是分成三部分存在的：对象头、实例数据、对其填充。

java对象头

在Hotspot虚拟机中，对象在内存中的存储布局，可以分为三块：对象头Header，实例数据Instance Data，对齐填充Padding。

Hotspot虚拟机的对象头包含了两部分信息：

Mark Word，用于存储对象自身的运行时数据，比如hash，gc分代年龄，锁状态的标志，线程持有锁，偏向ID，偏向时间戳等等
Klass Pointer：对象指向它的类的元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

32位HotSpot虚拟机的对象头存储结构如下

所以，对象头中的Mark Word，synchronized源码就是用了对象头中的Mark Word来标识对象加锁状态。

monitor

Monitor Record是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor record关联（对象头的MarkWord中的LockWord指向monitor record的起始地址），同时monitor record中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。如下图所示为Monitor Record的内部结构

线程唯一标识，当锁被释放时又设置为NULL； EntryQ:关联一个系统互斥锁（semaphore），阻塞所有试图锁住monitor record失败的线程。 RcThis:表示blocked或waiting在该monitor record上的所有线程的个数。 Nest:用来实现重入锁的计数。 HashCode:保存从对象头拷贝过来的HashCode值（可能还包含GC age）。

Candidate:用来避免不必要的阻塞或等待线程唤醒，因为每一次只有一个线程能够成功拥有锁，如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程，会引起不必要的上下文切换（从阻塞到就绪然后因为竞争锁失败又被阻塞）从而导致性能严重下降。Candidate只有两种可能的值0表示没有需要唤醒的线程1表示要唤醒一个继任线程来竞争

总结

简单总结一下，同步块使用monitorenter和monitorexit指令，而同步方法是依靠方法修饰符上的flag——ACC_SYNCHRONIZED来完成的。其本质都是对一个对象监视器monitor进行获取，这个获取过程是排他的，也就是同一时刻只能有一个线程获得由synchronized所保护的对象的监视器。而这个监视器，也可以理解为一个同步工具，它是由java对象进行描述的，在Hotspor中，是通过ObjectMonitor来实现，每个对象中天然都内置了一个ObjectMonitor对象。

在java中，synchronized在编译后，会在同步块的前后分别形成一个monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象，如果java程序中明确指定了对象，那就是这个对象的reference，如果没有指明，那么根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或者类Class对象来做锁对象。
在执行monitorenter时，首先会尝试获取对象的锁，如果这个对象没有锁，或者当前线程已经拥有了这个对象的锁，那个锁的计数器加1，相应的，在执行monitorexit时指令时，会将锁计数器减1，当计数器为0时，这个锁就被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另一个线程释放为止。

JVM对synchronized的优化

从最近几个jdk版本中可以看出，Java的开发团队一直在对synchronized优化，其中最大的一次优化就是在jdk6的时候，新增了两个锁状态，通过锁消除、锁粗化、自旋锁等方法使用各种场景，给synchronized性能带来了很大的提升。

5.1 锁膨胀

上面讲到锁有四种状态，并且会因实际情况进行膨胀升级，其膨胀方向是：无锁——>偏向锁——>轻量级锁——>重量级锁，并且膨胀方向不可逆。

5.1.1 偏向锁

一句话总结它的作用：减少统一线程获取锁的代价。在大多数情况下，锁不存在多线程竞争，总是由同一线程多次获得，那么此时就是偏向锁。

核心思想：

如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word的结构也就变为偏向锁结构，当该线程再次请求锁时，无需再做任何同步操作，即获取锁的过程只需要检查Mark Word的锁标记位为偏向锁以及当前线程ID等于Mark Word的ThreadID即可，这样就省去了大量有关锁申请的操作。

5.1.2 轻量级锁

轻量级锁是由偏向锁升级而来，当存在第二个线程申请同一个锁对象时，偏向锁就会立即升级为轻量级锁。注意这里的第二个线程只是申请锁，不存在两个线程同时竞争锁，可以是一前一后地交替执行同步块。

5.1.3 重量级锁

重量级锁是由轻量级锁升级而来，当同一时间有多个线程竞争锁时，锁就会被升级成重量级锁，此时其申请锁带来的开销也就变大。

重量级锁一般使用场景会在追求吞吐量，同步块或者同步方法执行时间较长的场景。

5.2 锁消除

消除锁是虚拟机另外一种锁的优化，这种优化更彻底，在JIT编译时，对运行上下文进行扫描，去除不可能存在竞争的锁。比如下面代码的method1和method2的执行效率是一样的，因为object锁是私有变量，不存在所得竞争关系。

5.3 锁粗化

锁粗化是虚拟机对另一种极端情况的优化处理，通过扩大锁的范围，避免反复加锁和释放锁。比如下面method3经过锁粗化优化之后就和method4执行效率一样了。

5.4 自旋锁与自适应自旋锁

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。

自旋锁：许多情况下，共享数据的锁定状态持续时间较短，切换线程不值得，通过让线程执行循环等待锁的释放，不让出CPU。如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式。但是它也存在缺点：如果锁被其他线程长时间占用，一直不释放CPU，会带来许多的性能开销。

自适应自旋锁：这种相当于是对上面自旋锁优化方式的进一步优化，它的自旋的次数不再固定，其自旋的次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，这就解决了自旋锁带来的缺点。

一、重量级锁

　　上篇文章中向大家介绍了Synchronized的用法及其实现的原理。现在我们应该知道，Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的。但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的。而操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。JDK中对Synchronized做的种种优化，其核心都是为了减少这种重量级锁的使用。JDK1.6以后，为了减少获得锁和释放锁所带来的性能消耗，提高性能，引入了“轻量级锁”和“偏向锁”。

二、轻量级锁

　　锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。JDK 1.6中默认是开启偏向锁和轻量级锁的，我们也可以通过-XX:-UseBiasedLocking来禁用偏向锁。锁的状态保存在对象的头文件中，以32位的JDK为例：

　　“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的。但是，首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用产生的性能消耗。在解释轻量级锁的执行过程之前，先明白一点，轻量级锁所适应的场景是线程交替执行同步块的情况，如果存在同一时间访问同一锁的情况，就会导致轻量级锁膨胀为重量级锁。

1、轻量级锁的加锁过程

　　（1）在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。这时候线程堆栈与对象头的状态如图2.1所示。

　　（2）拷贝对象头中的Mark Word复制到锁记录中。

　　（3）拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤（3），否则执行步骤（4）。

　　（4）如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图2.2所示。

　　（5）如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。而当前线程便尝试使用自旋来获取锁，自旋就是为了不让线程阻塞，而采用循环去获取锁的过程。

图2.1 轻量级锁CAS操作之前堆栈与对象的状态

图2.2 轻量级锁CAS操作之后堆栈与对象的状态

2、轻量级锁的解锁过程：

　　（1）通过CAS操作尝试把线程中复制的Displaced Mark Word对象替换当前的Mark Word。

　　（2）如果替换成功，整个同步过程就完成了。

　　（3）如果替换失败，说明有其他线程尝试过获取该锁（此时锁已膨胀），那就要在释放锁的同时，唤醒被挂起的线程。

三、偏向锁

　　引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。上面说过，轻量级锁是为了在线程交替执行同步块时提高性能，而偏向锁则是在只有一个线程执行同步块时进一步提高性能。

1、偏向锁获取过程：

　　（1）访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01——确认为可偏向状态。

　　（2）如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤（5），否则进入步骤（3）。

　　（3）如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行（5）；如果竞争失败，执行（4）。

　　（4）如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。

　　（5）执行同步代码。

2、偏向锁的释放：

　　偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。

3、重量级锁、轻量级锁和偏向锁之间转换

图 2.3三者的转换图

　　该图主要是对上述内容的总结，如果对上述内容有较好的了解的话，该图应该很容易看懂。

四、其他优化

1、适应性自旋（Adaptive Spinning）：从轻量级锁获取的流程中我们知道，当线程在获取轻量级锁的过程中执行CAS操作失败时，是要通过自旋来获取重量级锁的。问题在于，自旋是需要消耗CPU的，如果一直获取不到锁的话，那该线程就一直处在自旋状态，白白浪费CPU资源。解决这个问题最简单的办法就是指定自旋的次数，例如让其循环10次，如果还没获取到锁就进入阻塞状态。但是JDK采用了更聪明的方式——适应性自旋，简单来说就是线程如果自旋成功了，则下次自旋的次数会更多，如果自旋失败了，则自旋的次数就会减少。

**2、锁粗化（Lock Coarsening）：**锁粗化的概念应该比较好理解，就是将多次连接在一起的加锁、解锁操作合并为一次，将多个连续的锁扩展成一个范围更大的锁。举个例子：

package com.paddx.test.string;
 
public class StringBufferTest {
    StringBuffer stringBuffer = new StringBuffer();
 
    public void append(){
        stringBuffer.append("a");
        stringBuffer.append("b");
        stringBuffer.append("c");
    }
}

这里每次调用stringBuffer.append方法都需要加锁和解锁，如果虚拟机检测到有一系列连串的对同一个对象加锁和解锁操作，就会将其合并成一次范围更大的加锁和解锁操作，即在第一次append方法时进行加锁，最后一次append方法结束后进行解锁。

**3、锁消除（Lock Elimination）：**锁消除即删除不必要的加锁操作。根据代码逃逸技术，如果判断到一段代码中，堆上的数据不会逃逸出当前线程，那么可以认为这段代码是线程安全的，不必要加锁。看下面这段程序：

package com.paddx.test.concurrent;
 
public class SynchronizedTest02 {
 
    public static void main(String[] args) {
        SynchronizedTest02 test02 = new SynchronizedTest02();
        //启动预热
        for (int i = 0; i < 10000; i++) {
            i++;
        }
        long start = System.currentTimeMillis();
        for (int i = 0; i < 100000000; i++) {
            test02.append("abc", "def");
        }
        System.out.println("Time=" + (System.currentTimeMillis() - start));
    }
 
    public void append(String str1, String str2) {
        StringBuffer sb = new StringBuffer();
        sb.append(str1).append(str2);
    }
}

虽然StringBuffer的append是一个同步方法，但是这段程序中的StringBuffer属于一个局部变量，并且不会从该方法中逃逸出去，所以其实这过程是线程安全的，可以将锁消除。下面是我本地执行的结果：

　　为了尽量减少其他因素的影响，这里禁用了偏向锁（-XX:-UseBiasedLocking）。通过上面程序，可以看出消除锁以后性能还是有比较大提升的。

　　注：可能JDK各个版本之间执行的结果不尽相同，我这里采用的JDK版本为1.6。

五、总结

　　本文重点介绍了JDk中采用轻量级锁和偏向锁等对Synchronized的优化，但是这两种锁也不是完全没缺点的，比如竞争比较激烈的时候，不但无法提升效率，反而会降低效率，因为多了一个锁升级的过程，这个时候就需要通过-XX:-UseBiasedLocking来禁用偏向锁。下面是这几种锁的对比：

synchronized 重量级锁

1.6版本之前 synchronized 被称之为 重量级锁
1.6版本对 synchronized 进行了优化，主要优化的点在于 减少 获得锁和释放锁带
来的性能消耗，为实现这个目的引入了偏向锁、与轻量级锁。

synchronized 实现同步的基础

Java中每一个对象都可以作为锁。
普通同步方法，锁是当前实例对象。
静态同步方法块，锁是当前类的Class对象。
对于同步方法块，锁是synchronized括号里配置的对象。

synchronized 同步锁的获取底层原理

如下图所示：

synchronized 同步锁的获取底层原理.png

synchronized锁的存储位置

synchronized 用的锁是存在java对象头里的。
对象头中的Mark-word 默认存储对象的hashcode、分代年龄、和锁标志位。
Mark-word 中存储的数据会随着锁标志位的变化而变化
轻量级锁-00
重量级锁-10
GC标记-11
偏向锁-01

锁的升级与对比

Java SE 1.6 当中锁一共有4种状态，级别从低到高一次为:无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态。锁可以升级但不能降级，这种锁升级但不能降级的策略，目的是为了提高获得锁与释放锁的效率。

1.偏向锁原理

偏向锁的优点及初始化过程：

加锁解锁不需要额外的资源消耗，只需要对比当前线程id在对象头中是否存储指向当前线程的偏向锁。如果存在，表示当前线程已经获得锁。如果测试失败，则查询当前mark word中的偏向锁标志是否设置成为1，如果没有设置，则使用CAS竞争锁(非偏向锁状态)，如果设置了偏向锁标志，则尝试使用CAS将对象头的偏向锁指向当前线程。

偏向锁的撤销：

偏向锁使用了一种等到竞争出现才释放锁的机制，当其他线程尝试竞争偏向锁的时候，持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点，这个时间点上没有正在执行的字节码。它首先会暂停拥有偏向锁的线程，然后检查持有偏向锁的线程活着，如果线程不处于活动状态，则将对象头设置为无锁状态。如果线程仍活着，拥有偏向锁的栈会被执行完。

2.轻量级锁原理

轻量级锁加锁：

线程在执行同步块之前，JVM会先在当前线程的栈桢中创建存储锁记录的空间，并将对象头中的mark word 复制到锁记录当中，然后线程尝试使用CAS将对象头中的 mark word 替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋锁来获取锁。

轻量级锁解锁

轻量级解锁时，会使用原子的CAS将锁记录(Displaced Mark Word)替换回到对象头，如果成功，则表示没有发生竞争。如果失败，表示当前锁存在竞争，锁就会膨胀为重量级锁。

总结

不同锁的优缺点

2.ReentrantLock使用场景和实例

锁的种类

1.1 可重入锁

如果锁具备可重入性，则称作为可重入锁。synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举比如说，当一个线程执行到method1 的synchronized方法时，而在method1中会调用另外一个synchronized方法method2，此时该线程不必重新去申请锁，而是可以直接执行方法method2。

1.2 读写锁

读写锁将对一个资源的访问分成了2个锁，如文件，一个读锁和一个写锁。正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。可以通过readLock()获取读锁，通过writeLock()获取写锁。

1.3 可中断锁

可中断锁，即可以中断的锁。在Java中，synchronized就不是可中断锁，而Lock是可中断锁。如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。

Lock接口中的lockInterruptibly()方法就体现了Lock的可中断性。

1.4 公平锁

公平锁即尽量以请求锁的顺序来获取锁。同时有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该锁，这种就是公平锁。

非公平锁即无法保证锁的获取是按照请求锁的顺序进行的，这样就可能导致某个或者一些线程永远获取不到锁。

synchronized是非公平锁，它无法保证等待的线程获取锁的顺序。对于ReentrantLock和ReentrantReadWriteLock，默认情况下是非公平锁，但是可以设置为公平锁。

Condition：ReentrantLock提供了比Sync更精准的线程调度工具，Condition，一个lock可以有多个Condition，比如在生产消费的业务下，一个锁通过控制生产Condition和消费Condition精准控制。

可重入概念

若一个程序或子程序可以“安全的被并行执行(Parallel computing)”，则称其为可重入（reentrant或re-entrant）的。即当该子程序正在运行时，可以再次进入并执行它（并行执行时，个别的执行结果，都符合设计时的预期）。可重入概念是在单线程操作系统的时代提出的。

场景1：如果发现该操作已经在执行中则不再执行（有状态执行）

a、用在定时任务时，如果任务执行时间可能超过下次计划执行时间，确保该有状态任务只有一个正在执行，忽略重复触发。

b、用在界面交互时点击执行较长时间请求操作时，防止多次点击导致后台重复执行（忽略重复触发）。

以上两种情况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操作等）

场景2：如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）

这种比较常见大家也都在用，主要是防止资源使用冲突，保证同一时间内只有一个操作可以使用该资源。

但与synchronized的明显区别是性能优势（伴随jvm的优化这个差距在减小）。同时Lock有更灵活的锁定方式，公平锁与不公平锁，而synchronized永远是公平的。

这种情况主要用于对资源的争抢（如：文件操作，同步消息发送，有状态的操作等）

ReentrantLock默认情况下为不公平锁

不公平锁与公平锁的区别：

公平情况下，操作会排一个队按顺序执行，来保证执行顺序。（会消耗更多的时间来排队）

不公平情况下，是无序状态允许插队，jvm会自动计算如何处理更快速来调度插队。（如果不关心顺序，这个速度会更快）

场景3：如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）

这种其实属于场景2的改进，等待获得锁的操作有一个时间的限制，如果超时则放弃执行。

用来防止由于资源处理不当长时间占用导致死锁情况（大家都在等待资源，导致线程队列溢出）。

场景4：如果发现该操作已经在执行，等待执行。这时可中断正在进行的操作立刻释放锁继续下一操作

synchronized与Lock在默认情况下是不会响应中断(interrupt)操作，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景2的另一种改进，没有超时，只能等待中断或执行完毕）

这种情况主要用于取消某些操作对资源的占用。如：（取消正在同步运行的操作，来防止不正常操作长时间占用造成的阻塞）

下面是ReentrantLock的一个代码示例

//: concurrency/AttemptLocking.java  
// 以下是ReentrantLock中断机制的一个代码实现、如果换成synchronized就会出现死锁  
import java.util.concurrent.*;  
import java.util.concurrent.locks.*;  
 
public class AttemptLocking {  
    private ReentrantLock lock = new ReentrantLock();  
 
    public void untimed() {  
        boolean captured = lock.tryLock();  
        try {  
            System.out.println("tryLock(): " + captured);  
        } finally {  
            if (captured)  
                lock.unlock();  
        }  
    }  
 
    public void timed() {  
        boolean captured = false;  
        try {  
            captured = lock.tryLock(2, TimeUnit.SECONDS);  
        } catch (InterruptedException e) {  
            throw new RuntimeException(e);  
        }  
        try {  
            System.out.println("tryLock(2, TimeUnit.SECONDS): " + captured);  
        } finally {  
            if (captured)  
                lock.unlock();  
        }  
    }  
 
    public static void main(String[] args) throws InterruptedException {  
        final AttemptLocking al = new AttemptLocking();  
        al.untimed(); // True -- 可以成功获得锁  
        al.timed(); // True --可以成功获得锁  
        //新创建一个线程获得锁并且不释放  
        new Thread() {  
            {  
                setDaemon(true);  
            }  
 
            public void run() {  
                al.lock.lock();  
                System.out.println("acquired");  
            }  
        }.start();  
        Thread.sleep(100);// 保证新线程能够先执行  
        al.untimed(); // False -- 马上中断放弃  
        al.timed(); // False -- 等两秒超时后中断放弃  
    }  
}

synchronized和Lock有什么区别？

实现层面不一样。synchronized 是 Java 关键字，JVM层面实现加锁和释放锁；Lock 是一个接口，在代码层面实现加锁和释放锁
是否自动释放锁。synchronized 在线程代码执行完或出现异常时自动释放锁；Lock 不会自动释放锁，需要再 finally {} 代码块显式地中释放锁
是否一直等待。synchronized 会导致线程拿不到锁一直等待；Lock 可以设置尝试获取锁或者获取锁失败一定时间超时
获取锁成功是否可知。synchronized 无法得知是否获取锁成功；Lock 可以通过 tryLock 获得加锁是否成功
功能复杂性。synchronized 加锁可重入、不可中断、非公平；Lock 可重入、可判断、可公平和不公平、细分读写锁提高效率

3.1 synchronized和lock的区别

Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；
synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。
Lock可以提高多个线程进行读操作的效率。（可以通过readwritelock实现读写分离）
性能上来说，在资源竞争不激烈的情形下，Lock性能稍微比synchronized差点（编译程序通常会尽可能的进行优化synchronized）。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。

2.SpringBoot自动加载的原理

首先我们准备一个spring boot的项目，找到spring boot的启动类，它的结构大致是这样的

@SpringBootApplication
public class MiniWebApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(MiniWebApplication.class, args);
    }
 
}

我们知道，java程序执行都是从main方法开始的。在main中，执行了SpringApplication.run()方法，这个方法表示SpringApplication的执行入口。在执行run()方法的时候，SpringBoot就已经将所有的配置加载进来了。

@SpringBootApplicationSpring Boot应用标注在某个类上说明这个是SpringBoot的主配置类，SpringBoot应该允许类的main方法启动Spring Boot应用。

我们进入这个注解的定义可以看到：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {

@EnableAutoConfiguration，该注解为springboot自动加载配置信息的入口（@SpringBootApplication依赖该注解）

该注解告诉springboot扫描项目下的所有jar包，查找classpath:META-INF/spring.factories文件，加载该文件中的配置信息，格式如下：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=core.bean.MyConfig

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {

loadFactoryNames方法的作用是把/spring.factories文件中的配置类转化为对象，我们可以看到SpringApplication对象实例化时就是在这里加载META-INF/spring.factories文件。

@Import(AutoConfigurationImportSelector.class) 表示导入哪些组件的选择器，将所有需要导入的组件以全类名的方式返回，之后导入到spring容器中；

这里会导入非常多的自动配置类(xxxAutoConfiguration) 就是给容器中导入这个场景需要的所有组件，并配置好这些组件；免去了手动编写配置类的工作；

程序会在AutoConfigurationImportSelector类中读取配置，并将它们加载到bean容器中去。

protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
		List<String> configurations = SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(),
				getBeanClassLoader());
		Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories. If you "
				+ "are using a custom packaging, make sure that file is correct.");
		return configurations;
	}

Spring Boot在启动的时候，会去META-INF/spring.properties文件中获取EnableAutoConfiguration的指定的值，将这些值通过反射的方式将对应的类导入到容器中，自动配置类生效；

每一个xxxAutoConfiguration类都是容器中的一个组件，都可以加入到容器中，使用他们作为自动配置。这个时候每一个自动配置类进行自动配置。

Spring Boot 在启动的时候会自动加载默认配置，会对spring-boot-autoconfiguration包下的METF-INF/spring.factories文件进行扫描，读取可以加载到的类名，通过IOC将符合条件的类加载到容器中去。

每一个自动加载类都会有一个有参构造器，传入spring boot 默认以及用户的配置，这样就实现了自动加载配置的过程。