同步机制简介

线程同步机制是一套用于协调线程间的数据访问及活动的机制，该机制用于保障线程安全以及实现这些线程的共同目标。

线程同步机制是编程语言为多线程运行制定的一套规则，合理地运用这些规则可以很大程度上保障程序的正确运行。

这套机制包含两方面的内容，一是关于多线程间的数据访问的规则，二是多线程间活动的规则。前者关乎程序运行的正确与否，是相当重要的内容；后者很大程度上是影响程序的运行效率，也是不容忽视的内容。不太严谨地说，数据访问的规则主要是由锁来实现，线程间活动的规则则表现线程调度上。

锁

线程安全问题的产生前提是多个线程并发访问共享数据，那么一种保障线程安全的方法就是将多个线程对共享数据的并发访问转换为串行访问，即一个共享数据一次只能被一个线程访问，该线程访问结束后其他线程才能对其进行访问。锁就是利用这种思路来实现线程同步机制。

GoLang中换了个思路，通过通道（channel）来实现共享数据的安全性。

锁的相关概念

锁在编程里是个蛮有趣的概念。

锁：置于可启闭的器物上,以钥匙或暗码(如字码机构、时间机构、自动释放开关、磁性螺线管等)打开的扣件 ——在线新华字典

特定代码的作用域或是lock() 和unlock()方法之间的代码构成的区域就是“器物”的表征，线程访问其中的共享数据相当于解开“扣件”，打开了“器物”；通常所说“获得xx锁”，更像是获得了“钥匙或暗码”能够打开“扣件”的凭证。

说人话就是，锁在生活通常是“护卫”、“保护”的含义，应当是阻止进入或下一步行动的拒绝机制；在编程里略有不同，它一方面是指代了需要被保护代码（或数据）的范围，一方面又指代了进入受保护代码（或数据）的凭证。基于此，许多书与博客中的“申请锁”这说法才能说的通。不然，按生活常理，你获得了一把锁，没有钥匙好像也没什么用。

上述内容是本人的一点心得体会，不保证正确，不保证严谨

下面介绍与锁相关的一些概念。

临界区（Critical Section）：获得锁之后和释放锁之前的这段时间内执行的代码
内部锁（Intrinsic Lock）与显式锁（Explicit Lock）：按时Java虚拟机对锁实现的方式划分，内部锁（由关键字synchronized实现）与显式锁（Lock接口的实现类实现）
可重入性（Reentrancy）：一个线程在其持有一个锁的时候能否再次（或多次）申请该锁
锁的争用与调度：锁也可以被看作是一种排他性的资源，因此争用、调度概念也对锁适用。锁的调用基本上是Java虚拟机的设计者需要考虑的问题。Java平台中锁的调度策略包括了公平与非公平两种，内部锁属于非公平锁而显式锁则既支持公平锁又支持非公平锁
锁的粒度：一个锁实例所保护的共享数据的数量大小就被称为锁的粒度。但这是一个相对概念，应该根据实际情况来说明锁粒度的大小
如果有多个线程访问同一个锁所保护的共享数据，那么就你这些线程同步在这个锁上，或是对这些线程所访问的共享数据访问进行了加锁；相应地，这些线程所执行的临界区就被为这个锁所引导的临界区。
锁的排他、互斥：都是指一个锁一次只能被一个线程所持有的特性。

以上就是与锁相关的一些概念，这些概念也比较通用，在其他编程语言里或多或少也会有它们的身影。

内部锁：`synchronized`关键字

Java平台中任何一个对象都有唯一一个与之关联的锁。这种锁被称为监视器或是内部锁。内部锁是一种排他锁，它能保障原子性、可见性和有序性。

内部锁通过synchronized关键字实现的。synchronized关键字可以修饰方法及代码块。修饰方法时，此方法被称为同步（静态/实例）方法；修饰代码块时，被称为同步（静态）代码块。

同步方法

synchronized修饰的方法被称为同步方法。同步方法的整个方法体就是一个临界区。

public synchronized void sayHello(){
     // do something
}

同步静态方法相当于以当前类对象为引导锁的同步块。

同步块

synchronized (锁句柄){
// do something
}

synchronized关键字所引导的代码块就是临界区。锁句柄是一个对象的引用。锁句柄可以填写this关键字，表示当前对象。习惯上也直接称锁句柄为锁。锁句柄对应的监视器就被称为相应同步块的引导锁。相应地，我们称呼相应的同步为该锁引导的同步块。
作为锁句柄的变量通常采用final修饰。这是因为锁句柄变量的值一旦改变，会导致执行同一个同步块的多个线程实际上使用不同的锁，从而导致竞态。因而，锁句柄的变量通常声明形式为private final Object lock = new Object();

特性

线程在执行临界区代码时必须持有该临界区的引导锁。一个线程执行到同步块（同步方法也可看作是同步块）时必须先申请该同步块的引导锁，只有申请成功该的线程才能够执行相应的临界区。一个线程执行完成临界区代码后引导该临界区的锁就会被自动释放。在这个过程中，线程对内部锁申请与释放的动作由Java虚拟机负责完成，这也是synchronized实现的锁被称之为内部锁的原因。
内部锁的使用并不会导致锁泄漏。Java编译器对同步块代码作了特殊的处理，这使得临界区的代码即使抛出异常也不会妨碍内部锁的释放。

内部锁的调度

Java虚拟机会为每个内部锁分配一个入口集，用于记录等待获得相应内部锁的线程。多个线程申请同一个锁的时候，只有一个申请都能够成为该锁的持有线程（即申请锁成功），而其他申请者的申请操作会失败。这些申请失败的线程并不会抛出异常，而是会被暂停（生命周期状态变为BLOCKED）并被存入相应锁的入口集中等待再申请锁的机会。入口集中的线程就被称为相应内部锁的等待线程。当该内部锁被释放时，入口集中的任意线程会被Java虚拟机唤醒，得到再次申请锁的机会。由于是非公平的高度，被唤醒的等待处理器运行时可能还有其他新和活跃线程（RUNNABLE状态且未进入过入口集）与该线程抢占这个被释放的锁，因此被唤醒的线程不一定就能成为该锁的持有线程。另外，Java虚拟机从入口集中选择一个等待线程的算法与虚拟机具体实现有关，总的来说是随机的。（像极了女神和她的备胎们）

显式锁：`Lock`接口

显式锁是自JDK1.5引入的排他锁，其作用与内部锁大致相同，并额外提供些特性。

显式锁是java.util.concurrent.locks.Lock接口的实例。该接口对显式锁进行了抽象，类java.uitl.concurrent.locks.ReentrantLock是它默认实现类。

使用模版：

private final Lock lock = ....; // 一个Lock接口的实例
...
lock.lock(); // 申请锁
try{
// do something
}finally{
lock.unlock(); // 手动释放锁，避免锁泄漏
}

显式锁支持公平调度，但开销相对较大，默认使用非公平调度。

改进型锁：读写锁

锁的排他性使得多个线程无法以线程安全的方式在同一时刻对变量进行读取（只读不更新），不利于提高系统的并发性。
读写锁（Read/Write Lock）是一种改进型的排他锁，也被称为共享/排他锁（Shared/Exclusive Lock）。读写锁允许多个线程可以同时读取（只读）共享变量，但是一次只允许一个线程对共享变量进行更新（包括读取后再更新）。任何线程读取变量的时候，其他线程无法更新这些变量；一个线程更新共享变量的时候，其他任何线程都无法访问该变量。

轻量级同步机制：`volatile`关键字

volatile有“易挥发”的意思，引申为“不稳定”。volatile关键字用于修饰共享可变变量，即没有使用final关键字修饰的实例变量或静态变量，相应的变量被称为volatile变量。

volatile关键字表示被修饰的变量的值容易变化（即被其他线程更改），因而不稳定。volatile变量的不稳定性意味着对这种变量的读写操作都必须从高速缓存或者主内存中读取，以获取变量的相对新值。因些，volatile变量不会被编译器分配到寄存器进行存储，对volatile变量的读写操作都是内存访问操作。

volatile关键字常被称为轻量级锁，其作用与锁的作用有相同的地方：保证可见性的有序性。在原子性方面，它仅能保障写volatile变量操作的原子性，但没有锁的排他性；其次，volatile关键字的使用不会引起上下文切换（正是“轻量级”的原因）。

作用

volatile关键字的作用包括：保障可见性、有序性和long/double型变量读写操作的原子性（不是赋值操作）。
某些32位Java虚拟机上long/double型变量写操作不具有原子性，加上volatile关键字后，其读写操作本身就具有了原子性。一般地，对于volatile变量的赋值操作，其右边表达式中涉及共享变量（包括赋值的volatile变量本身），那么这个同仁操作就不是原子操作，要保障这样操作的原子性，仍然需要锁。
读线程对volatile变量读取操作会产生类似于获得锁的效果；写线程则会产生类似于释放锁的效果；因此，volatile具有保障有序性和可见性的作用。
如果volatile变量是数组，那么volatile关键字只能对数组引用本身的操作起作用（读取数组引用和更新数组引用），而无法对数组元素的操作起作用（读取、更新数组元素）。

开销

总的来说，读写操作成本介于普通变量写和在临界区内进行读写操作之间。

CAS指令

CAS（Compare and Swap）是对一种处理器指令的称呼，不少多线程相关的Java标准库类的实现最终都会借助CAS，实际中大多数情况不会直接使用。
对于简单的自增操作count++来说，使用锁的开销过大，使用volatile又不能保证原子性，这种情况下可以使用CAS。它能将read-modify-write和check-and-act之类操作转换为原子操作，其实现如伪代码所示：

boolean compareAndSwap(Variable v ,Object oldVal ,Object newVal){
    if (oldVal == v.get()){ // check: 检查变量值是否被其他线程修改过
        v.set(newVal); // act:更新变量值
        return true; // 更新成功
    }
    return false; // 变量值被其他线程修改，更新失败
}

CAS操作前提假设是：如果变量v的当前值和客户请求（即调用）CAS时所提供的变量值（即变量的旧值）是相等的，那么就说明其他线程并没有修改过变量v的值，可以执行更新值的操作。其他线程更新值的操作则会失败。
这个假设并不一定总能成立。

ABA 问题

对于共享变量v，当前线程看到它的值为A的那一刻，其他线程已经将其值更新为B，接着在当前线程执行CAS时该变量又被其他线程更新为A了，这就是ABA问题。
对ABA 问题接受度与要实现的算法有关，某些情况下无法接受ABA问题的存在。ABA问题常引入修订号来解决，即用[共享变量实际值，修改号]这样的元组来表示共享变量的值，AtomicStampedReference类就是基于这种思想实现的。

原子变量类

原子变量类比锁的粒度更细，更轻量级，并且对于在多处理器系统上实现高性能的并发代码来说是非常关键的。原子变量将发生竞争的范围缩小到单个变量上。
原子变量类相当于一种泛化的 volatile 变量，能够支持原子的、有条件的读/改/写操作。
原子类在内部使用 CAS 指令（基于硬件的支持）来实现同步。这些指令通常比锁更快。
原子变量类可分为4组：

分组	类
基础数据型	AtomicBoolean AtomicInteger AtomicLong
数组型	AtomicIntegerArray AtomicLongArray AtomicReferenceArray
字段更新器	AtomicIntegerFieldUpdater AtomicLongFieldUpdater AtomicStampedReference
引用型	AtomicReference AtomicReferenceFieldUpdater AtomicMarkableReference