数据竞争（Data Race）
数据共享读， 数据可写（会发生变化）
竞态条件（Race Condition）
- 多线程、进程操作（读写）共享数据的最终结果取决于进程、线程执行的时序（顺序）;如if(a>0) a++,可能执行一次a++也可能执行多次a++;
互斥
进程、线程竞争使用具有排它性的共享资源。
临界资源
临界资源、互斥资源或者共享变量（一次值允许一个进程、线程使用）。
临界区（互斥区）
对临界资源实施操作的程序片段
同步
系统中多个进程、线程中发生的事件存在某种时序关系，需要相互合作，共同完成一项任务。
关键字：多*程，通信，时序（协作）
同步机制
为何叫同步机制，而不是叫别的？？因为常常把互斥看做一种特殊的同步，实际上同步机制技能解决互斥问题也能解决同步问题，
线程上下文
是指再某一时间CPU寄存器和程序计数器的内容
Tss任务状态段，位于内存中的一段数据
经典同步机制-信号量以及PV操作
信号量：
描述：进程、线程间传递信息的一个整数值
定义：
struc semaphore{
int count
queueType queue;//等待队列
}
操作：初始化 ，P和V（P、v分别是荷兰语的test(proberen）和 increment(verhogen))
| P | V |
|---|---|
| DOWN | UP |
| - | + |
p(s){
s.count--;
if(s.count < 0){
该进程状态设置为阻塞状态；
将该进程插入s.queue这个等待队列末尾
进程、线程让出cpu，操作系统调度选择新的线程、进程来运行；
}
//如果count 不小于0 ,那么继承继续持有cpu，继续运行。
}
v(s){
s.count++;
if(s.count <= 0){
唤醒s.queue这个等待队中等待的一个进程；
将其状态设置为就绪态，并将其插入就绪队列。
}
//如果count > 0，继续持有cpu，继续运行。
}
如何解决互斥和同步的问题？
同步机制-管程
- PV操作由程序员控制容易出错，提供更方便的并发处理操作。
- 由关于共享资源的数据结构以及在其上操作的一组过程组成
- 进程只能通过调用管程中的过程来间接地访问管程中的数据结构。
- 有标示以区分
如何解决互斥和同步问题
- 互斥问题：
1 管程是互斥进入（为了保证管程中数据结构的数据完整性）
2 管程的互斥性是由编译器负责保证的。 - 同步问题
1 管程中设置条件变量，等待/唤醒操作，以解决同步问题。
1.1 条件变量
1.2 等待操作:可以让进程、线程在条件变量上等待（此时，应先释放管程的使用权，不然别其它线程、进程拿不到使用权）；
1.3 发信号操作:也可以通过发送信号将等待在条件变量上的进程、线程唤醒。
管程的大麻烦
HOARE管程
Q等待
Q被放置到条件变量等待队列中。
P唤醒Q P等待Q执行;
1.Q在条件变量队列中被移除唤醒，
2.P被放置到紧急等待队列中，
3.优先级 紧急等待队列 > 入口等待队列
缺点：两次进程、线程切换
P唤醒Q，P：活动，Q：等待
P等待Q, P: 休眠，Q:激活；Q执行完，P激活。
条件变量的实现
- 在管程内部声明和使用
- 对条件变量执行wait和signal操作
wait(c)操作：
- 如果紧急等待队列非空，则唤醒第一个等待者（不施放管程的互斥权，入口等待队列的优先级低，不让执行）；
- 否则释放管程的互斥权
- 执行此操作的进程进入C链末端
signal(c)操作：
c:链为空，则相当于空操作，执行此操作的进程继续执行；否则唤醒第一个等待着，执行此操作的进程进入紧急等待队列末尾。
管程的实现
实现途径：
- 直接构造：语言中自带管程
- 间接构造： 用某种已经实现的同步机制去构造（比如用信号量和PV操作来构造管程）
MESA管程
notify强调了不进行进程/线程切换，发信号的进程/线程继续执行。
notify的结果：位于条件变量等待队列头部（第一个wait）的进程在将来合适的时候，且当处理器可用时恢复执行，即不是notify后，立即执行。
不能保证在它执行前，条件变量内容没变(1.可能其他的进程进入管程,修改了条件,2notify()方法 到 到线程退出前这区间的代码修改了条件)，因此这个进程必须重新检查条件。用while循环取代if
导致对条件变量至少多一次额外的检测，但不再有额外的进程切换；并且对等待进程在notify之后何时运行没有任何限制。
对notify改进
1.wait(long timeout);给每个条件原语关联一个监视计时器，无论是否被通知，一个等待时间超时的进程都可以被设置为就绪状态；当该进程被调度执行时，会再次检查相关的条件，如果满足则继续执行。
3.超时可以防止这种情况，当某些进程/线程 在notify之前就挂掉，等待该条件的进程/线程会处于饥饿状态，永远的等下去；引入broadcast:使所有在该条件上等待的进程都被释放并进入就绪队列。
- 当不知道多少进程被激活时候，这种方式非常方便。
- 无法判准确判读按激活那个进程/线程，也可以使用广播。
CAS
CAS(Compare and swap )：比较并交换
白话说是 ，如果你是nn的情况下（比较），那么我才要把你更新成mm（交换）；如果..那么.. 对应 and；所以是比较并交换。
JUC里的AtomicInteger,AtomicBoolean,AtomicLong等内部都用CAS操作来实现原子操作的功能。
ABA
ABA是一种现象，即从A变为B，又从B变为A，如果第一次看到第一个A，第二次看到第二个A, 两个A都是A，好像没有变化，但是其实漏掉中间状态B。如果我们的程序要求区分第一个A和第二个A，即认为两个A不同，且能区别，那只能通过附加的版本信息来标识区分。举个例子昨天的你和今天的你 都是你 ，但是又不是相同的你，如何区分两个你呢，比如今天的你是xx年xx月xx日的你，那么昨天的你就是xx年xx月mm日的你，附加上版本信息（这里用了日期）。
数据库的乐观锁，一般也都是采用加上一个Version字段，不但目标值要相同，版本也要相同。
JUC中的AtomicStampedReference，就是提供引用+stamp（版本）的方式来增强CAS的实现，我们可以借助它来避免ABA问题
自旋
while(xxx){
//获取最新的值
currentValue = get();
// cas操作成功了，就退出；
if(true == CAS(... , currentValue,destValue)){
break;
}
//cas操作不成功，继续循环。这个循环的线程中不会主动的释放CPU的使用权。
}
公平锁 && 非公平锁
多个线程都申请持有锁，锁同一时刻只能被一个线程持有；
当持有锁的线程使用完毕，释放锁之后，其他线程开始抢占锁，其中一个线程拿到锁之后，其他线程等待锁释放后再争夺。
- 公平锁 ： 申请抢占锁的线程排队，当锁被释放后，先申请的将先得到锁；缺点，os激活线程是随机的，如果激活的不是队列头一个，就得放弃本次激活的线程的使用，再次执行线程调度。直到激活的线程是等待队列头的线程。
- 非公平锁：当锁被释放后，哪个线程持有锁不遵守申请的顺序，而根据os对线程的调度的结果，哪个线程被优先唤醒，哪个线程就持有锁。
- 公平锁的缺点：等待队列头的线程可能要经历n次线程调度才能被唤醒；这n次线程调度用时多久不确定。