synchronized关键字是Java并发中的一个重要内容，它能够解决多个线程之间访问资源的同步性。
作用范围
由于synchronized是关键字，所以它能够修饰三个地方的代码，分别是：实例方法、静态方法、代码块。
实例方法
当synchronized修饰某个实例的方法时，它的锁对象为当前对象实例：
synchronized void test() {
......
}因为锁对象是当前对象实例，所以若是对象实例不同，则无法保证线程同步。
静态方法
当synchronized修饰某个静态方法时，它的锁对象为当前类的Class对象：
synchronized static void test() {
......
}因为锁对象是当前类的Class对象，所以即使对象实例不同，只要范围是在这个类中，则能保证线程同步。
代码块
代码块比较特殊，它需要指定锁对象是谁：
synchronized(TestDemo.class){
......
}synchronized是如何保证线程同步的
不知道大家有没有好奇过，synchronized是如何保证线程同步的呢？我们以一段程序为例：
public class LockDemo {
public static void main(String[] args) {
synchronized (LockDemo.class) {
System.out.println("执行业务代码......");
}
}
}对该程序进行反编译得到如下指令集：
Code:
stack=2, locals=3, args_size=1
0: ldc #2 // class com/wwj/lock/LockDemo
2: dup
3: astore_1
4: monitorenter
5: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
8: ldc #4 // String 执行业务代码......
10: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
13: aload_1
14: monitorexit
15: goto 23
18: astore_2
19: aload_1
20: monitorexit
21: aload_2
22: athrow
23: return不难发现，我们的业务代码被两个指令包裹住了，分别是monitorenter和monitorexit。
原来，synchronized的底层是通过C++编写的Monitor监视器实现的，具体细节可以查阅底层源代码 objectMonitor.cpp：
从指令集中我们也可以发现一些细节，第14条和第20条指令均为monitorexit，按照我们的理解，monitorenter就是加锁，monitorexit就是解锁，难道程序解锁了两次？其实并不是，我们找到这段程序的Exception Table：
Exception table:
from to target type
5 15 18 any
18 21 18 any由此得出结论，当第5条至第15条指令出现异常时，JVM会直接来到第18条指令继续执行，也就是说，当我们加锁的业务出现了异常时，JVM是会自动帮助我们释放锁的。
synchronized在JVM层面的实现
在JVM中，对象在内存中的存储结构可以分为以下三个区域：
- 对象头
- 实例数据
- 对齐填充
而在对象头中又分为两个部分，分别是类型指针和运行时数据（也称为Mark Word），其中类型指针用于指定当前对象的类型，而运行时数据里又存放了以下数据（这里只是简单例举几个）：
- GC分代年龄
- 对象的hashCode
- 线程持有的锁
- 偏向锁ID
- 偏向时间戳
在JDK1.6之后，官方对synchronized进行了较大的升级，使得synchronized具有了四种锁的状态，分别是无锁、偏向锁、轻量级锁和重量级锁，对象头中专门划分出了一块区域用于存储锁标志位，来区分synchronized的各种锁状态，如图：
在64位的JVM中，对象头共占用12个字节，其中类型指针占用4个字节32位，Mark Word部分占用8字节64位。
由上表可知，锁标志位对应的锁状态，比如01表示无锁或偏向锁，如果是偏向锁还需要记录线程ID、偏向时间戳等内容；00则表示轻量级锁；10表示重量级锁。
将锁划分成四个状态有什么好处呢？原来在JDK1.6以前，synchronized总是以重量级锁的形式作用于程序中，由此导致它的性能低下。而JDK1.6之后，synchronized并不会直接加上重量级锁。
偏向锁
比如，当某个线程访问同步代码时，就会在对象头的Mark Word中记录线程ID，以后该线程在进入和退出同步代码时只需要比较一下Mark Word中的线程ID是否匹配，如果是，则表示获取了锁（由此可知synchronized是可重入锁），否则就会使用CAS将Mark Word中的线程ID设置为当前线程。当某个代码块总是只有一个线程在进入和退出时，为其设置偏向锁可以大大提升性能，因为偏向锁没有加锁解锁的过程，仅仅是判断了Mark Word中的数据值而已。
偏向锁使用的是等到竞争出现才释放锁的机制，当某个其它线程想要来竞争偏向锁时，持有偏向锁的线程就需要释放锁，但必须等待全局安全点的出现才能释放，此时需要检查持有偏向锁的线程是否存活，若存活，则Mark Word中的线程ID需要重新指定为某个线程或者设置为无锁状态；否则直接设置为无锁状态。
轻量级锁
当偏向锁被两个线程竞争时，偏向锁失效，锁升级为轻量级锁。
比如线程A、线程B同时竞争偏向锁C，则线程A、B需要将C的Mark Word复制到自己的锁记录中，然后某个线程会尝试使用CAS操作将C中Mark Word的线程ID设置为自己的锁记录指针，若成功，则获取到锁，此时其它线程的CAS操作就会失败，其它线程进入自旋等待。当业务执行完毕释放锁时，线程A继续使用CAS操作将之前复制的C中的Mark Word重新设置到C中，如果成功，则解锁成功，如果失败，则锁升级为重量级锁。
需要注意的是当某个线程在自旋等待获取锁时，为了保证效率，它的自旋次数是有限制的，默认最多自旋10次，当超过10次后线程仍未获取到锁，则锁也会被升级为重量级锁。
重量级锁
当锁升级到重量级锁之后，synchronized就重新回到JDK1.6之前的状态了，底层仍然是依赖于C++实现的Monitor监视器。
总结
通过上述的内容，我们可以将synchronized与Lock进行一些比较：
- synchronized和Lock都是可重入锁
- synchronized依赖于JVM，是JVM的具体实现；Lock依赖于API，是API层面的实现
- synchronized出现异常会自动释放锁；Lock必须手动释放
- synchronized是非公平锁；Lock既可以是公平锁，也可以是非公平锁
- Lock能够让某个等待锁的线程停止等待锁释放；synchronized无法做到
- synchronized无法知道线程是否获取到了锁；而Lock可以
