多个执行线程共享一个资源的情景，是并发编程中最常见的情景之一。多个线程读或者写相同的数据等情况时可能会导致数据不一致。为了解决这些问题，引入了临界区概念。临界区是一个用以访问共享资源的代码块，这个代码块在同一时间内只允许一个线程执行。
　　Java多线程使用锁机制来实现同步以保证数据安全。当一个线程试图访问一个临界区时，它将使用一种同步机制来查看是不是已有其他线程进入临界区。如果没有其他线程进入临界区，它就可以进入临界区；如果已有线程进入了临界区，它就被同步机制挂起，直到进入的线程离开这个临界区。如果在等待进入临界区的线程不止一个，JVM会随机选择其中的一个，其余的将继续等待。

使用synchronized实现同步

　　每一个用synchronized关键字声明的方法都是临界区。在Java中，同一个对象的临界区，在同一时间只有一个允许被访问。
　　注意：用synchronized关键字声明的静态方法，同时只能被一个执行线程访问，但是其他线程可以访问这个对象的非静态方法。即：两个线程可以同时访问一个对象的两个不同的synchronized方法，其中一个是静态方法，一个是非静态方法。了解了synchronized关键字的作用，再来看一下synchronized关键字的使用方式。
　　首先看修饰静态方法

1
2
3

static synchronized void method() {
  //something
}

　　或

1
2
3
4
5

static void method() {
  synchronized(Demo.class){
    //something
  }
}

　　下面是修饰非静态方法

1
2
3

synchronized void method() {
  //something
}

　　或

1
2
3
4
5

void method() {
  synchronized(this){
    //something
  }
}

　　需要注意的是，synchronized修饰静态方法防止多个线程同时访问这个类中的synchronized static 方法。它会对对类的所有对象实例起作用。然而，synchronized修饰非静态方法则可以防止多个线程同时访问这个对象的synchronized方法（如果一个对象有多个synchronized方法，只要一个线 程访问了其中的一个synchronized方法，其它线程不能同时访问这个对象中任何一个synchronized方法）。这时，不同的对象实例的 synchronized方法是不相干扰的。也就是说，其它线程照样可以同时访问相同类的另一个对象实例中的synchronized方法。

synchronized 代码块

　　除了方法前用synchronized关键字，synchronized关键字还可以用于方法中的某个区块中，表示只对这个区块的资源实行互斥访问。用法是: synchronized(this){/区块/}，它的作用域是当前对象。这时锁就是对象，谁拿到这个锁谁就可以运行它所控制的那段代码。当有一个明确的对象作为锁时，就可以这样写程序，但当没有明确的对象作为锁，只是想让一段代码同步时，可以创建一个特殊的instance变量（它得是一个对象）来充当锁：

1
2
3
4
5
6
7
8

class MyRunnable implements Runnable {
       private byte[] lock = new byte[0]; // 特殊的instance变量    
       public void methodA() {      
         synchronized(lock) {
            //something
            }
       }
}

　　需要注意下面的问题：
　　1、synchronized关键字会降低应用程序的性能，因此只能在并发场景中修改共享数据的方法上使用它。
　　2、临界区的访问应该尽可能的短。方法的其余部分保持在synchronized代码块之外，以获取更好的性能

使用Lock实现同步

　　除了使用synchronized外，还可以使用Lock对象来创建临界区。它比synchronized关键字更强大也更加灵活。这种机制基于Lock接口及其实现类（例如：ReentrantLock）
　　它比synchronized关键字好的地方：
　　1、提供了更多的功能。tryLock()方法的实现，这个方法试图获取锁，如果锁已经被其他线程占用，它将返回false并继续往下执行代码。
　　2、Lock接口允许分离读和写操作，允许多个线程读和只有一个写线程。ReentrantReadWriteLock
　　3、具有更好的性能
　　使用范式如下示例：

1
2
3
4
5
6
7
8

Lock lock = new ReentrantLock();  
lock.lock();  
try {   
  // update object state  
}  
finally {  
  lock.unlock();
}

　　可以看到 Lock 和 synchronized 有一点明显的区别 —— lock 必须在 finally 块中释放。否则，如果受保护的代码将抛出异常，锁就有可能永远得不到释放。

锁的概念以及分类

　　公平锁和非公平锁
　　公平锁是指多个线程在等待同一个锁时，必须按照申请锁的先后顺序来一次获得锁。
　　公平锁的好处是等待锁的线程不会饿死，但是整体效率相对低一些；非公平锁的好处是整体效率相对高一些，但是有些线程可能会饿死或者说很早就在等待锁，但要等很久才会获得锁。其中的原因是公平锁是严格按照请求所的顺序来排队获得锁的，而非公平锁时可以抢占的，即如果在某个时刻有线程需要获取锁，而这个时候刚好锁可用，那么这个线程会直接抢占，而这时阻塞在等待队列的线程则不会被唤醒。
　　公平锁可以使用new ReentrantLock(true)实现。

　　自旋锁
　　Java的线程是映射到操作系统的原生线程之上的，如果要阻塞或唤醒一个线程，都需要操作系统来帮忙完成，这就需要从用户态转换到核心态中，因此状态装换需要耗费很多的处理器时间，对于代码简单的同步块（如被synchronized修饰的getter()和setter()方法），状态转换消耗的时间有可能比用户代码执行的时间还要长。
　　虚拟机的开发团队注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间取挂起和恢复现场并不值得。如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一下“，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。
　　自旋等待不能代替阻塞。自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，因此，如果锁被占用的时间很短，自旋当代的效果就会非常好，反之，如果锁被占用的时间很长，那么自旋的线程只会拜拜浪费处理器资源。因此，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用-XX:PreBlockSpin来更改）没有成功获得锁，就应当使用传统的方式去挂起线程了。
　　自旋是在轻量级锁中使用的，在重量级锁中，线程不使用自旋。
　　如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如100次循环。另外，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。

　　锁消除
　　锁消除是虚拟机JIT在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判断依据是来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而能被其他线程访问到，那就可以把他们当做栈上数据对待，认为他们是线程私有的，同步加锁自然就无需进行。
来看这样一个方法：

1
2
3
4
5
6
7
8

public String concatString(String s1, String s2, String s3)
   {
       StringBuffer sb = new StringBuffer();
       sb.append(s1);
       sb.append(s2);
       sb.append(s3);
       return sb.toString();
   }

　　可以知道StringBuffer 的append方法定义如下：

1
2
3
4

public synchronized StringBuffer append(StringBuffer sb) {
        super.append(sb);
        return this;
    }

　　也就是说在concatString()方法中涉及了同步操作。但是可以观察到sb对象它的作用域被限制在方法的内部，也就是sb对象不会“逃逸”出去，其他线程无法访问。因此，虽然这里有锁，但是可以被安全的消除，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。

　　锁粗化
　　原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制的尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁禁止，那等待的线程也能尽快拿到锁。大部分情况下，这些都是正确的。但是，如果一些列的联系操作都是同一个对象反复加上和解锁，甚至加锁操作是出现在循环体中的，那么即使没有线程竞争，频繁地进行互斥同步操作也导致不必要的性能损耗。
　　举个案例，类似锁消除的concatString()方法。如果StringBuffer sb = new StringBuffer();定义在方法体之外，那么就会有线程竞争，但是每个append()操作都对同一个对象反复加锁解锁，那么虚拟机探测到有这样的情况的话，会把加锁同步的范围扩展到整个操作序列的外部，即扩展到第一个append()操作之前和最后一个append()操作之后，这样的一个锁范围扩展的操作就称之为锁粗化。

　　可重入锁
　　可重入锁，也叫做递归锁，指的是同一线程外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。在JAVA环境下 ReentrantLock 和synchronized 都是可重入锁。可重入锁最大的作用是避免死锁。

　　悲观锁和乐观锁
　　悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
　　乐观锁：假定不会发生并发冲突，只在提交操作时检测是否违反数据完整性。（使用版本号或者时间戳来配合实现）

　　共享锁和排它锁
　　共享锁：如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排它锁。获准共享锁的事务只能读数据，不能修改数据。
　　排它锁：如果事务T对数据A加上排它锁后，则其他事务不能再对A加任何类型的锁。获得排它锁的事务即能读数据又能修改数据。

　　读写锁
　　读写锁是一个资源能够被多个读线程访问，或者被一个写线程访问但不能同时存在读线程。Java当中的读写锁通过ReentrantReadWriteLock实现。

　　互斥锁
　　所谓互斥锁就是指一次最多只能有一个线程持有的锁。在JDK中synchronized和JUC的Lock就是互斥锁。

　　无锁
　　要保证线程安全，并不是一定就要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性的手段，如果一个方法本来就不涉及共享数据，那它自然就无须任何同步措施去保证正确性，因此会有一些代码天生就是线程安全的。
　　1、线程本地存储。可以参考ThreadLocal
　　2、volatile
　　3、CAS
　　4、协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。