1.摘要

我对多线程问题一直处于一种似懂非懂的状态，针对不同语言、不同操作系统的线程同步方法经常会产生混淆。这篇文章总结了几类场景下的线程同步方法，并且（在未来将会）比较它们的异同。

2. Windows下的线程同步

2.1. 临界区（Critical Section）

通过对多线程的串行化来访问 公共资源或一段代码，速度快，适合控 制数据访问。在任意时刻只允许一个线程对共享资源进行访问。如果有多个线程试图同时访问临界区，那么在有一个线程进入后其他所有试图访问此临界区的线程将 被挂起，并一直持续到进入临界区的线程离开。临界区在被释放后，其他线程可以继续抢占，并以此达到用原子方式操作共享资源的目的。

临界区包含两个操作原语：

EnterCriticalSection（） 进入临界区

LeaveCriticalSection（） 离开临界区

EnterCriticalSection（） 语句执行后代码将进入临界区以后无论发生什么，必须确保与之匹配的LeaveCriticalSection（）都能够被执行到。否则临界区保护的共享资 源将永远不会被释放。虽然临界区同步速度很快，但却只能用来同步本进程内的线程，而不可用来同步多个进程中的线程。

2.2. 互斥量（Mutex）

互 斥量跟临界区很相似，只有拥有互斥对象的线程才具有访问资源的权限，由于互斥对象只有一个，因此就决定了任何情况下此共享资源都不会同时被多个线程所访 问。当前占据资源的线程在任务处理完后应将拥有的互斥对象交出，以便其他线程在获得后得以访问资源。而且可以在不同应用程序的线程之间实现对资源的安全共 享。

互斥量包含的几个操作原语：

CreateMutex（） 创建一个互斥量

OpenMutex（） 打开一个互斥量

ReleaseMutex（） 释放互斥量

WaitForMultipleObjects（） 等待互斥量对象

互斥量使用方式推荐：

用RAII 手法封装mutex 的创建、销毁、加锁、解锁这四个操作。

只用非递归的mutex（即不可重入的mutex）。

不手工调用lock() 和unlock() 函数，一切交给栈上的Guard 对象的构造和析构函数负责，Guard 对象的生命期正好等于临界区。这样我们保证在同一个函数里加锁和解锁，避免在foo() 里加锁，然后跑到bar() 里解锁。

在每次构造Guard 对象的时候，思考调用栈上已经持有的锁，防止因加锁顺序不同而导致死锁(deadlock)。由于Guard 对象是栈上对象，看函数调用栈就能分析用锁的情况，非常便利。

尽量不使用跨进程的mutex，进程间通信只用TCP sockets。

加锁解锁在同一个线程，线程a 不能去unlock 线程b 已经锁住的mutex。（ RAII自动保证）

别忘了解锁。（RAII 自动保证）

不重复解锁。（RAII 自动保证）

必要的时候可以考虑用PTHREAD_MUTEX_ERRORCHECK 来排错

2.3. 信号量（Semaphore）

信 号允许多个线程同时使用共享资源，这与操作系统中的PV操作相同。它指出了同时访问共享资源的线程最大数目。它允许多个线程在同一时刻访问同一资源，但 是需要限制在同一时刻访问此资源的最大线程数目。在用CreateSemaphore（）创建信号量时即要同时指出允许的最大资源计数和当前可用资源计 数。一般是将当前可用资源计数设置为最大资源计数，每增加一个线程对共享资源的访问，当前可用资源计数就会减1，只要当前可用资源计数是大于0的，就可以 发出信号量信号。但是当前可用计数减小到0时则说明当前占用资源的线程数已经达到了所允许的最大数目，不能在允许其他线程的进入，此时的信号量信号将无法 发出。线程在处理完共享资源后，应在离开的同时通过ReleaseSemaphore（）函数将当前可用资源计数加1。在任何时候当前可用资源计数决不可 能大于最大资源计数。

PV操作及信号量的概念都是由荷兰科学家E.W.Dijkstra提出的。信号量S是一个整数，S大于等于零时代表可供并发进程使用的资源实体数，但S小于零时则表示正在等待使用共享资源的进程数。

P操作 申请资源：

（1）S减1；

（2）若S减1后仍大于等于零，则进程继续执行；

（3）若S减1后小于零，则该进程被阻塞后进入与该信号相对应的队列中，然后转入进程调度。

V操作 释放资源：

（1）S加1；

（2）若相加结果大于零，则进程继续执行；

（3）若相加结果小于等于零，则从该信号的等待队列中唤醒一个等待进程，然后再返回原进程继续执行或转入进程调度。

信号量包含的几个操作原语：

CreateSemaphore（） 创建一个信号量

OpenSemaphore（） 打开一个信号量

ReleaseSemaphore（） 释放信号量

WaitForSingleObject（） 等待信号量

2.4. 事件（Event）

事件对象也可以通过通知操作的方式来保持线程的同步。并且可以实现不同进程中的线程同步操作。事件包含的几个操作原语：

CreateEvent（） 创建一个事件

OpenEvent（） 打开一个事件

SetEvent（） 回置事件

WaitForSingleObject（） 等待一个事件

WaitForMultipleObjects（） 等待多个事件

WaitForMultipleObjects 函数原型：

WaitForMultipleObjects（

IN DWORD nCount, // 等待句柄数

IN CONST HANDLE *lpHandles, //指向句柄数组

IN BOOL bWaitAll, //是否完全等待标志

IN DWORD dwMilliseconds //等待时间

）

参 数nCount指定了要等待的内核对象的数目，存放这些内核对象的数组由lpHandles来指向。fWaitAll对指定的这nCount个内核对象 的两种等待方式进行了指定，为TRUE时当所有对象都被通知时函数才会返回，为FALSE则只要其中任何一个得到通知就可以返回。 dwMilliseconds在这里的作用与在WaitForSingleObject（）中的作用是完全一致的。如果等待超时，函数将返回 WAIT_TIMEOUT。

2.5. 条件变量

条件变量(condition variable) 顾名思义是一个或多个线程等待某个布尔表达式为真，即等待别的线程“唤醒”它。条件变量的学名叫管程(monitor)。Java Object 内置的wait(),notify(), notifyAll() 即是条件变量（它们以容易用错著称）。条件变量只有一种正确使用的方式，对于wait() 端：

1. 必须与mutex 一起使用，该布尔表达式的读写需受此mutex 保护

2. 在mutex 已上锁的时候才能调用wait()

3. 把判断布尔条件和wait() 放到while 循环中

3. Linux下的线程同步

3.1. Mutex（互斥量）

与windows下类似
常见的互斥体有两种：
非递归互斥体(nonrecursive mutex)：如果当前拥有互斥体的线程在没有首先释放它的情况，试图再次获得它，就会导致死锁或失败。
递归互斥体(recursive mutex)：拥有互斥体的线程可能多次获得它而不会产生自死锁，只要这个线程最终以相同次数释放这个互斥体即可。

2.5. 条件变量

条件变量使我们可以睡眠等待某种条件出现。
条件变量是利用线程间共享的全局变量进行同步的一种机制，主要包括两个动作：一个线程等待"条件变量的条件成立"而挂起；另一个线程使"条件成立"（给出条件成立信号）。为了防止竞争，条件变量的使用总是和一个互斥锁结合在一起。
条件变量类型为pthread_cond_t
创建和注销
条件变量和互斥锁一样，都有静态动态两种创建方式，静态方式使用PTHREAD_COND_INITIALIZER常量，如下：
pthread_cond_t cond=PTHREAD_COND_INITIALIZER
动态方式调用pthread_cond_init()函数，API定义如下：
int pthread_cond_init(pthread_cond_t *cond, pthread_condattr_t *cond_attr)
尽管POSIX标准中为条件变量定义了属性，但在LinuxThreads中没有实现，因此cond_attr值通常为NULL，且被忽略。
注销一个条件变量需要调用pthread_cond_destroy()，只有在没有线程在该条件变量上等待的时候才能注销这个条件变量，否则返回EBUSY。API定义如下：
int pthread_cond_destroy(pthread_cond_t *cond)
等待和激发
int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)
int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime)
等 待条件有两种方式：无条件等待pthread_cond_wait()和计时等待pthread_cond_timedwait()，其中计时等待方式如 果在给定时刻前条件没有满足，则返回ETIMEOUT，结束等待，其中abstime以与time()系统调用相同意义的绝对时间形式出现，0表示格林尼 治时间1970年1月1日0时0分0秒。
使用绝对时间而非相对时间的优点是。如果函数提前返回（很可能因为捕获了一个信号，）
无论哪种等 待方式，都必须和一个互斥锁配合，以防止多个线程同时请求pthread_cond_wait()（或 pthread_cond_timedwait()，下同）的竞争条件（Race Condition）。mutex互斥锁必须是普通锁（PTHREAD_MUTEX_TIMED_NP）或者适应锁 （PTHREAD_MUTEX_ADAPTIVE_NP），且在调用pthread_cond_wait()前必须由本线程加锁 （pthread_mutex_lock()），而在更新条件等待队列以前，mutex保持锁定状态，并在线程挂起进入等待前解锁。在条件满足从而离开 pthread_cond_wait()之前，mutex将被重新加锁，以与进入pthread_cond_wait()前的加锁动作对应。
激发条件有两种形式，pthread_cond_signal()激活一个等待该条件的线程，存在多个等待线程时按入队顺序激活其中一个；而pthread_cond_broadcast()则激活所有等待线程。
其他
pthread_cond_wait() 和pthread_cond_timedwait()都被实现为取消点，因此，在该处等待的线程将立即重新运行，在重新锁定mutex后离开 pthread_cond_wait()，然后执行取消动作。也就是说如果pthread_cond_wait()被取消，mutex是保持锁定状态的， 因而需要定义退出回调函数来为其解锁。
以下示例集中演示了互斥锁和条件变量的结合使用，以及取消对于条件等待动作的影响。在例子中，有两个线程被 启动，并等待同一个条件变量，如果不使用退出回调函数（见范例中的注释部分），则tid2将在pthread_mutex_lock()处永久等待。如果 使用回调函数，则tid2的条件等待及主线程的条件激发都能正常工作。

3.3. 自旋锁

自旋锁是专为防止多处理器并发而引入的一种锁，它在内核中大量应用于中断处理等部分(对于单处理器来说，防止中断处理中的并发可简单采用关闭中断的方式，不需要自旋锁)。
自旋锁最多只能被一个内核任务持有，如果一个内核任务试图请求一个已被争用(已经被持有)的自旋锁，那么这个任务就会一直进行忙循环——旋转——等待锁重 新可用。要是锁未被争用，请求它的内核任务便能立刻得到它并且继续进行。自旋锁可以在任何时刻防止多于一个的内核任务同时进入临界区，因此这种锁可有效地 避免多处理器上并发运行的内核任务竞争共享资源。
事实上，自旋锁的初衷就是：在短期间内进行轻量级的锁定。一个被争用的自旋锁使得请求它的线程在等待锁重新可用的期间进行自旋(特别浪费处理器时间)，所以自旋锁不应该被持有时间过长。如果需要长时间锁定的话, 最好使用信号量。
自旋锁的基本形式如下：
spin_lock(&mr_lock);
//临界区
spin_unlock(&mr_lock);
因为自旋锁在同一时刻只能被最多一个内核任务持有，所以一个时刻只有一个线程允许存在于临界区中。这点很好地满足了对称多处理机器需要的锁定服务。在单处 理器上，自旋锁仅仅当作一个设置内核抢占的开关。如果内核抢占也不存在，那么自旋锁会在编译时被完全剔除出内核。
简单的说，自旋锁在内核中主要用来防止多处理器中并发访问临界区，防止内核抢占造成的竞争。另外自旋锁不允许任务睡眠(持有自旋锁的任务睡眠会造成自死锁 ——因为睡眠有可能造成持有锁的内核任务被重新调度，而再次申请自己已持有的锁)，它能够在中断上下文中使用。
死锁：假设有一个或多个内核任务和一个或多个资源，每个内核都在等待其中的一个资源，但所有的资源都已经被占用了。这便会发生所有内核任务都在相互等待， 但它们永远不会释放已经占有的资源，于是任何内核任务都无法获得所需要的资源，无法继续运行，这便意味着死锁发生了。自死琐是说自己占有了某个资源，然后 自己又申请自己已占有的资源，显然不可能再获得该资源，因此就自缚手脚了。

3.4. 读写锁（rwlock）

读写锁实际 是一种特殊的自旋锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作。这种锁相对于自旋锁而言， 能提高并发性，因为在多处理器系统中，它允许同时有多个读者来访问共享资源，最大可能的读者数为实际的逻辑CPU数。写者是排他性的，一个读写锁同时只能 有一个写者或多个读者（与CPU数相关），但不能同时既有读者又有写者。

在读写锁保持期间也是抢占失效的。

如果读写锁当前没有读者，也没有写者，那么写者可以立刻获得读写锁，否则它必须自旋在那里，直到没有任何写者或读者。如果读写锁没有写者，那么读者可以立即获得该读写锁，否则读者必须自旋在那里，直到写者释放该读写锁。

1. 特性:

一次只有一个线程可以占有写模式的读写锁, 但是可以有多个线程同时占有读模式的读写锁. 正是因为这个特性,

当读写锁是写加锁状态时, 在这个锁被解锁之前, 所有试图对这个锁加锁的线程都会被阻塞.

当读写锁在读加锁状态时, 所有试图以读模式对它进行加锁的线程都可以得到访问权, 但是如果线程希望以写模式对此锁进行加锁, 它必须直到知道所有的线程释放锁.

通常, 当读写锁处于读模式锁住状态时, 如果有另外线程试图以写模式加锁, 读写锁通常会阻塞随后的读模式锁请求, 这样可以避免读模式锁长期占用, 而等待的写模式锁请求长期阻塞.

2. 适用性:

读写锁适合于对数据结构的读次数比写次数多得多的情况. 因为, 读模式锁定时可以共享, 以写模式锁住时意味着独占, 所以读写锁又叫共享-独占锁.

3.5. 信号量

从 概念上说，信号量(semaphore)是可以原子(automically)递增和背叛的非负整数。如果一个线程试图递减一个信号量，但这个信号量的值 已经为0，则线程将会阻塞。另一个线程“发出(post)”这个信号(semaphore)，使用信号量大于0之后，被阻塞的线程才会被释放。

信 号量维护状态信息，对信号计数值(count)和被阻塞线程的数量进行记录。它们一般是通过“休止锁(sleep lock)”来实现的；休止锁用来触发环境切换，以允许其他线程执行。和互斥体不同的是，释放信号量的线程不必是最初获得这个信号量的线程。这使得信号量 适用于更广泛的执行环境，如信号处理程序或中断处理程序。

Linux中的信号量是一种睡眠锁。如果有一个任务试图获得一个已被持有的信号量时，信号量会将其推入等待队列，然后让其睡眠。这时处理器获得自由去执行其它代码。当持有信号量的进程将信号量释放后，在等待队列中的一个任务将被唤醒，从而便可以获得这个信号量。

信号量的睡眠特性，使得信号量适用于锁会被长时间持有的情况；只能在进程上下文中使用，因为中断上下文中是不能被调度的；另外当代码持有信号量时，不可以再持有自旋锁。

信号量基本使用形式为：
static DECLARE_MUTEX(mr_sem);//声明互斥信号量
if(down_interruptible(&mr_sem))
//可被中断的睡眠，当信号来到，睡眠的任务被唤醒
//临界区
up(&mr_sem);

如 果代码需要睡眠——这往往是发生在和用户空间同步时，使用信号量是唯一的选择。由于不受睡眠的限制，使用信号量通常来说更加简单一些。如果需要在自旋锁 和信号量中作选择，应该取决于锁被持有的时间长短。理想情况是所有的锁都应该尽可能短的被持有，但是如果锁的持有时间较长的话，使用信号量是更好的选择。 另外，信号量不同于自旋锁，它不会关闭内核抢占，所以持有信号量的代码可以被抢占。这意味者信号量不会对影响调度反应时间带来负面影响。

4. Java下的线程同步

4.1. synchronized

每 个java对象都有一把锁， 当有多个线程同时访问共享资源的时候， 需要Synchronize 来控制安全性， synchronize 分 synchronize 方法 和synchronize块，使用synchronize块时， 一定要显示的获得该对象的锁（如synchronize（object))而方法则不需要。
可修饰：方法、静态方法、代码块（对象）、代码块（类）

4.2. 可重入锁Lock

synchronized与java.util.concurrent.locks.Lock 的异同。
要相同点：Lock能完成synchronized所实现的所有功能
     主要不同点：Lock有比synchronized更精确的线程语义和更好的性能。synchronized会自动释放 锁，而Lock一定要求程序员手工释放，并且必须在finally从句中释放。

ReentrantLock锁
ReentrantLock是“一个可重入的互斥锁 Lock，它具有与使用 synchronized  方法和语句所访问的隐式监视器锁相同的一些基本行为和语义，但功能更强大。
ReentrantLock 将由最近成功获得锁，并且还没有释放该锁的线程所拥有。当锁没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁并返回。如果当前线程已经拥有该锁，此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。 ”

简单来说，ReentrantLock有一个与锁相关的获取计 数器，如果拥有锁的某个线程再次得到锁，那么获取计数器就加1，然后锁需要被释放两次才能获得真正释放。这模仿了 synchronized 的语义；如果线程进入由线程已经拥有的监控器保护的 synchronized 块，就允许线程继续进行，当线程退出第二个（或者后续） synchronized 块的时候，不释放锁，只有线程退出它进入的监控器保护的第一个 synchronized 块时，才释放锁。

ReentrantLock  类（重入锁）实现了 Lock ，它拥有与 synchronized 相同的并发性和内存语义，但是添加了类似锁投票、定时锁等候和可中断锁等候的一些特性。此外，它还提供了在激烈争用情况下更佳的性 能。（换句话说，当许多线程都想访问共享资源时，JVM 可以花更少的时候来调度线程，把更多时间用在执行线程上。）

ReentrantLock 有一个带布尔型参数的构造函数。此类的构造方法接受一个可选的公平 参数。当设置为 true 时，在多个线程的争用下，这些锁倾向于将访问权授予等待时间最长的线程。否则此锁将无法保证任何特定访问顺序。与采用默认设置（使用不公平锁）相比，使用 公平锁的程序在许多线程访问时表现为很低的总体吞吐量（即速度很慢，常常极其慢），但是在获得锁和保证锁分配的均衡性时差异较小。不过要注意的是，公平锁 不能保证线程调度的公平性。因此，使用公平锁的众多线程中的一员可能获得多倍的成功机会，这种情况发生在其他活动线程没有被处理并且目前并未持有锁时。还 要注意的是，未定时的 tryLock  方法并没有使用公平设置。因为即使其他线程正在等待，只要该锁是可用的，此方法就可以获得成功。

4.3. wait()/notify()/notifyAll()

在 synchronized代码被执行期间，线程可以调用对象的wait()方法，释放对象锁标志，进入等待状态，并且可以调用notify()或者  notifyAll()方法通知正在等待的其他线程。notify()通知等待队列中的第一个线程，notifyAll()通知的是等待队列中的所有线 程。
obj.wait()方法将使本线程挂起，并释放obj对象的monitor。只有其他线程调用obj对象的notify()或notifyAll()时，才可以被唤醒。
obj.notifyAll()方法唤醒所有该obj对象相关的沉睡线程，然后被唤醒的众多线程开始竞争obj对象的monitor占有权，最终得到的那个线程会继续执行下去，但其他线程还将继续等待。
obj.notify()方法是随机唤醒一个沉睡线程。
wait，notify和notifyAll只能在同步控制方法或者同步控制块里面使用，
类似上文中的条件变量。

4.4. ThreadLocal

其 实ThreadLocal并非是一个线程的本地实现版本，它并不是一个Thread，而是threadlocalvariable(线程局部变量)。也许 把它命名为ThreadLocalVar更加合适。线程局部变量(ThreadLocal)其实的功用非常简单，就是为每一个使用该变量的线程都提供一个 变量值的副本，是Java中一种较为特殊的线程绑定机制，是每一个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。

从线程的角度看，每个线程都保持一个对其线程局部变量副本的隐式引用，只要线程是活动的并且 ThreadLocal 实例是可访问的；在线程消失之后，其线程局部实例的所有副本都会被垃圾回收（除非存在对这些副本的其他引用）。

通过ThreadLocal存取的数据，总是与当前线程相关，也就是说，JVM 为每个运行的线程，绑定了私有的本地实例存取空间，从而为多线程环境常出现的并发访问问题提供了一种隔离机制。

ThreadLocal是如何做到为每一个线程维护变量的副本的呢？其实实现的思路很简单，在ThreadLocal类中有一个Map，用于存储每一个线程的变量的副本。

概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。

ThreadLocal()
创建一个线程本地变量。

T get()
返回此线程局部变量的当前线程副本中的值，如果这是线程第一次调用该方法，则创建并初始化此副本。

protected  T initialValue()
返回此线程局部变量的当前线程的初始值。最多在每次访问线程来获得每个线程局部变量时调用此方法一次，即线程第一次使用 get() 方法访问变量的时候。如果线程先于 get 方法调用 set(T) 方法，则不会在线程中再调用 initialValue 方法。

若该实现只返回 null；如果程序员希望将线程局部变量初始化为 null 以外的某个值，则必须为 ThreadLocal 创建子类，并重写此方法。通常，将使用匿名内部类。initialValue 的典型实现将调用一个适当的构造方法，并返回新构造的对象。

void remove()
移除此线程局部变量的值。这可能有助于减少线程局部变量的存储需求。如果再次访问此线程局部变量，那么在默认情况下它将拥有其 initialValue。

void set(T value)
将此线程局部变量的当前线程副本中的值设置为指定值。许多应用程序不需要这项功能，它们只依赖于 initialValue() 方法来设置线程局部变量的值。

在程序中一般都重写initialValue方法，以给定一个特定的初始值。

5. 参考文章

秒杀多线程系列文章
进程和线程的总结
同步机制——互斥体锁、读/写锁、信号量锁、条件变量
linux条件变量用法
Java线程同步 （synchronized wait notify）
java线程同步原理及wait,notify的用法及与sleep的区别
Java 多线程同步问题的探究（三、Lock来了，大家都让开【1. 认识重入锁】）