1 线程安全性
当多个线程访问某个类时，不管运行时环境采用何种调度方式或者这些进程将如何交替执行，并且在主调代码中不需要额外的同步和协同，这个类都能表现出正确的行为。
线程安全性主要体现在以下三个方面:
- 原子性：提供了互斥访问，同一时刻只能有一个线程来对它进行操作。
- 可见性：一个线程对主内存的修改可以及时的被其它线程观察到。
- 有序性：一个线程观察其他线程中的指令执行顺序，由于指令重排序的存在，该观察结果一般杂乱无序。
1.1 原子性
由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write，我们大致可以认为基本数据类型的访问读写是具备原子性的(例外就是long和double的非原子协定，读者只要知道这件事就可以了，无须太过于在意这些几乎不会发生的例外情况)。
如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlcok操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式使用这两个操作。这两个字节码指令反映到Java代码中就是同步块 - synchronized。
1.1.1 Atomic原子性实现
Atomic的包名为java.util.concurrent.atomic。这个包里面提供了一组原子变量的操作类，这些类可以保证在多线程环境下，当某个线程在执行atomic的方法时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由JVM从等待队列中选择一个线程执行。
Atomic包的实现主要基于CAS(Compare And Set)操作，我们开篇提供了一个计数器的功能，发现每次执行结果没有达到预期，在之前版本做稍许改动
@Slf4j
@ThreadSafe
public class AtomicExample1 {
// 请求总数
public static int clientTotal = 5000;
// 同时并发执行的线程数
public static int threadTotal = 200;
public static AtomicInteger count = new AtomicInteger(0);
public static void main(String[] args) throws Exception {
ExecutorService executorService = Executors.newCachedThreadPool();
final Semaphore semaphore = new Semaphore(threadTotal);
final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
for (int i = 0; i < clientTotal ; i++) {
executorService.execute(() -> {
try {
semaphore.acquire();
add();
semaphore.release();
} catch (Exception e) {
log.error("exception", e);
}
countDownLatch.countDown();
});
}
countDownLatch.await();
executorService.shutdown();
log.info("count:{}", count.get());
}
private static void add() {
count.incrementAndGet();
// count.getAndIncrement();
}
}
//每次能达到预期效果
我们一起看看AtomicInteger的incrementAndGet的内部实现，其余几个方法的原理跟这个相同，在此不再过多的解释
/**
* 当前值自增1
*/
public final int incrementAndGet() {
//Unsafe是JDK内部用的工具类。它通过暴露一些Java意义上说“不安全”的功能给Java层代码
return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
/**
* AtomicInteger 中的CAS操作就是compareAndSet()，其作用是每次从内存中
*根据内存偏移量（valueOffset）取出数据，将取出的值跟expect 比较，如果数据一致就把内存中的值改为update。这样使用CAS就保证了原子操作
* @param expect the expected value
* @param update the new value
* @return {@code true} if successful. False return indicates that
* the actual value was not equal to the expected value.
*/
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
关于Atomic我们说最后一点,CAS的ABA问题，如count=1，A线程在获取值的时候,count值可能被其它线程改变但最终改回成了1。导致与实现思想有偏差，为了解决这个请参考AtomicStampedReference的实现，修改对应一个版本号
public boolean compareAndSet(V expectedReference,
V newReference,
int expectedStamp,
int newStamp) {
Pair<V> current = pair;
return
//在之前CAS操作的基础上添加了版本号的比较
expectedReference == current.reference &&
expectedStamp == current.stamp &&
((newReference == current.reference &&
newStamp == current.stamp) ||
casPair(current, Pair.of(newReference, newStamp)));
}
1.1.2 Synchronized原子性实现
- 修饰代码块：大括号括起来的代码，作用于调用对象。
- 修饰方法：整个方法，作用于调用对象。
- 修饰静态方法：整个静态方法，作用于所有对象。
- 修饰类：括号括起来的部分，作用于所有对象。
//修饰代码块
synchronized (this) { ... }
//修饰方法
public synchronized void test(int j) { ... }
//修饰静态方法
public static synchronized void test2(int j){ ... }
//修饰类
synchronized (SynchronizedExample2.class) { ... }
1.1.3 原子性-对比
-Synchronized：不可中断锁，适合竞争不激烈，可读性好。
-Lock：可中断锁，多样化同步，竞争激烈时能维持常态。
-Atomic：竞争激烈时能维持常态，比Lock性能好；只能同步一个值。
1.2 可见性
Java内存模型中，允许编译器和处理器指令进行重排序，重排序并不会影响到单线程的执行，却会影响到多线程的执行。
可见性是指当一个线程修改了共享变量的值，其它线程能够立即得知这个修改。从前面//www.greatytc.com/p/9005b30c0fe2章节我们了解到Java内存模型是通过在变量修改后将新值同步回主存,在变量读取前从主内存刷新变量值这种依赖主存作为传递媒介的方式来实现可见性的。
导致共享变量在线程间不可见的原因：
- 线程交叉执行
- 重排序结合线程交叉执行
- 共享变量更新后的值没有在工作内存与主内存及时更新
1.2.1 Synchronized可见性实现
JMM关于synchronized的两条规定
- 线程解锁前，必须把共享变量的最新值刷新到主内存。
- 线程加锁时，将清空工作内存共享变量的值，从而使用共享变量时需要从主内存重新读取共享变量的值(加锁和解锁必须为同一把锁)
1.2.2 Volatile可见性实现
通过内存屏障和禁止重排序优化来实现。
- 对Volatile变量写操作时，会在写操作后加入一条store屏障指令，将本地内存中共享变量值刷新到主内存。
-
对Volatile变量读操作时，会在读操作前加入一条load指令，从主内存读取共享变量的值。
Volatile写.png
关于Volatile变量的可见性，经常会被开发人员误解，认为以下描述成立:"volatile变量对所有线程是立即可见的，对volatile变量所有的写操作都能立刻反应到其它线程中，换句话说，volatile变量在各个线程中是一致的，所以基于volatile变量的运算在并发下是安全的"，这句话的论据没有错，但是论据并不能得出"基于volatile变量的运算在并发下是安全的"，因为Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样不安全，我们还是通过计数器的例子来说明原因。
@Slf4j
@NotThreadSafe
public class CountExample4 {
// 请求总数
public static int clientTotal = 5000;
// 同时并发执行的线程数
public static int threadTotal = 200;
public static volatile int count = 0;
public static void main(String[] args) throws Exception {
ExecutorService executorService = Executors.newCachedThreadPool();
final Semaphore semaphore = new Semaphore(threadTotal);
final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
for (int i = 0; i < clientTotal ; i++) {
executorService.execute(() -> {
try {
semaphore.acquire();
add();
semaphore.release();
} catch (Exception e) {
log.error("exception", e);
}
countDownLatch.countDown();
});
}
countDownLatch.await();
executorService.shutdown();
log.info("count:{}", count);
}
private static void add() {
count++;
//可能在往主存回写的时候出现问题
// 1、count
// 2、+1
// 3、count
}
}
1.3 有序性
如果在本线程内观察，所有的操作都是有序的；如果一个线程中观察另外一个线程，所有操作都是无序的。前半句是指"线程内表现为串行的语义"，后半句是指"指令重排序"现象和"工作内存与主内存同步延迟"现象。
Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由"一个变量在同一时刻只允许一条线程对其进行lock操作"这条规则获得。
1.3.1 Happens-before原则
如果Java内存模型中所有的有序性都仅仅靠volatile和synchronized来完成，那么有一些操作将会变得很繁琐，但是我们在编写并发代码时并没有感觉到这一点，这是因为Java语言有一个"先行发生"(happens-before)的原则
//以下操作在线程A执行
i = 1;
//以下操作在线程B执行
j = i;
//以下操作在线程C执行
i = 2;
//假设线程A中的操作先行发生于线程B的操作，那么可以确定在线程B操作执行后，变量j的值一定等于1，得出结论依据有两个：一是根据先行发生原则，i=1的结果可以被观察到； 二是线程C还没有登场；假设A还是先行于B，但是线程C出现在A、B之间，但是线程C与B没有先行发生的关系，此时j的值就可能变得不确定了，1和2都有可能
下面是Java内存模型下一些"天然的"先行发生关系，这些先行发生关系无须任何同步器协助就存在。
- 程序次序规则：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说，应该是控制流顺序而不是代码顺序，因为要考虑分支、循环等结构。
- 管程锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调是同一个锁，而"后面"是指时间上的先后顺序。
- volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的"后面"同样是值时间上的先后顺序。
- 线程启动规则：Thread对象的start()方法先行发生于此线程的每一个动作。
- 线程终止规则：线程中的所有操作都先行发生于对此线程的终止监测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。
-线程中断规则: 对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断时间的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。 - 对象终结规则:：一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。
-传递性：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。
