i++ 是线程安全的吗？
例子
先来看下面的示例来验证下 i++ 到底是不是线程安全的。
1000个线程，每个线程对共享变量 count 进行 1000 次 ++ 操作。
上面的例子我们期望的结果应该是 1000000，但运行 N 遍，你会发现总是不为 1000000，至少你现在知道了 i++
操作它不是线程安全的了。
JMM 模型中对共享变量的读写原理。
每个线程都有自己的工作内存，每个线程需要对共享变量操作时必须先把共享变量从主内存 load 到自己的工作内存，等完成对共享变量的操作时再 save 到主内存。
问题就出在这了，如果一个线程运算完后还没刷到主内存，此时这个共享变量的值被另外一个线程从主内存读取到了，这个时候读取的数据就是脏数据了，它会覆盖其他线程计算完的值。。。
这也是经典的内存不可见问题，那么把 count 加上 volatile 让内存可见是否能解决这个问题呢？ 答案是：不能。因为
volatile 只能保证可见性，不能保证原子性。多个线程同时读取这个共享变量的值，就算保证其他线程修改的可见性，也不能保证线程之间读取到同样的值然后相互覆盖对方的值的情况。
关于多线程的几种关键概念请翻阅《多线程之原子性、可见性、有序性详解》这篇文章。
解决方案
- 说了这么多，对于 i++ 这种线程不安全问题有没有其他解决方案呢？当然有，请参考以下几种解决方案。
1、对 i++ 操作的方法加同步锁，同时只能有一个线程执行 i++ 操作；
2、使用支持原子性操作的类，如 java.util.concurrent.atomic.AtomicInteger，它使用的是
CAS 算法，效率优于第 1 种;
拓展
CAS算法
CAS：Compare and Swap, 翻译成比较并交换。链接描述
java.util.concurrent包中借助CAS实现了区别于synchronouse同步锁的一种乐观锁，使用这些类在多核CPU的机器上会有比较好的性能.
CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。
今天我们主要是针对AtomicInteger的incrementAndGet做深入分析。
/**
* Atomically increments by one the current value.
*
* @return the updated value
*/
public final int incrementAndGet() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return next;
}
}循环的内容是：
1.取得当前值
2.计算+1后的值
3.如果当前值没有被覆盖的话设置那个+1后的值
4.如果设置没成功, 再从1开始
在这个方法中可以看到compareAndSet这个方法，我们进入看一下。
/**
* Atomically sets the value to the given updated value
* if the current value {@code ==} the expected value.
*
* @param expect the expected value
* @param update the new value
* @return 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);
}调用UnSafe这个类的compareAndSwapInt
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
JAVA程序也就跟踪到这里为止了，剩下的就是通过JNI调用C程序了，可是我奇怪的是为什么变量名都是var1，var2这样的命名呢？JAVA编程规范不是说不使用1，2等没有含义的字符命名吗？
JNI原生实现部分
在openJDK中找到找到unsafe.cpp这个文件，代码如下：
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
UnsafeWrapper("Unsafe_CompareAndSwapInt");
oop p = JNIHandles::resolve(obj);
jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
UNSAFE_END核心方法是compxchg，这个方法所属的类文件是在OS_CPU目录下面，由此可以看出这个类是和CPU操作有关，进入代码如下：
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
// alternative for InterlockedCompareExchange
int mp = os::is_MP();
__asm {
mov edx, dest
mov ecx, exchange_value
mov eax, compare_value
LOCK_IF_MP(mp)
cmpxchg dword ptr [edx], ecx
}
}这个方法里面都是汇编指命，看到LOCK_IF_MP也有锁指令实现的原子操作，其实CAS也算是有锁操作，只不过是由CPU来触发，比synchronized性能好的多。
使用cas的类
ReenTrantLock、countDownLatch、AtomicInteger
ReenTrantLock和synchronized比较
可重入性：
从名字上理解，ReenTrantLock的字面意思就是再进入的锁，其实synchronized关键字所使用的锁也是可重入的，两者关于这个的区别不大。两者都是同一个线程没进入一次，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。
锁的实现：
Synchronized是依赖于JVM实现的，而ReenTrantLock是JDK实现的，有什么区别，说白了就类似于操作系统来控制实现和用户自己敲代码实现的区别。前者的实现是比较难见到的，后者有直接的源码可供阅读。
性能的区别：
在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。
功能区别：
便利性：很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。
锁的细粒度和灵活度：很明显ReenTrantLock优于Synchronized
ReenTrantLock独有的能力：
1.ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。
2.ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。
3.ReenTrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。
ReenTrantLock实现的原理：
在网上看到相关的源码分析，本来这块应该是本文的核心，但是感觉比较复杂就不一一详解了，简单来说，ReenTrantLock的实现是一种自旋锁，通过循环调用CAS(无锁算法)操作来实现加锁。它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设计的关键钥匙。
CAS和synchronized适用场景
1、对于资源竞争较少的情况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源；而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。
2、对于资源竞争严重的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。以java.util.concurrent.atomic包中AtomicInteger类为例，其getAndIncrement()方法实现如下：
如果compareAndSet(current, next)方法成功执行，则直接返回；如果线程竞争激烈，导致compareAndSet(current, next)方法一直不能成功执行，则会一直循环等待，直到耗尽cpu分配给该线程的时间片，从而大幅降低效率。
java共享锁实现原理及CountDownLatch解析 链接描述
CountDownLatch使用解说
例子1： CountDownLatch是java5中新增的一个并发工具类，其使用非常简单，下面通过伪代码简单看一下使用方式：
这是一个使用CountDownLatch非常简单的例子，创建的时候，需要指定一个初始状态值，本例为2，主线程调用 latch.await时，除非latch状态值为0，否则会一直阻塞休眠。当所有任务执行完后，主线程唤醒，最终执行打印动作。
例子2：以上只是一个最简单的例子，接着咱们再来看一个，这回，咱们想要在任务执行完后做更多的事情，如下图所示：
这一次，在线程3和线程4中，分别调用了latch.await()，当latch状态值为0时，这两个线程将会继续执行任务，但是顺序性是无法保证的。
CountDownLatch的方便之处在于，你可以在一个线程中使用，也可以在多个线程上使用，一切只依据状态值，这样便不会受限于任何的场景。
java共享锁模型
在java5提供的并发包下，有一个AbstractQueuedSynchronizer抽象类，也叫AQS，此类根据大部分并发共性作了一些抽象，便于开发者实现如排他锁，共享锁，条件等待等更高级的业务功能。它通过使用CAS和队列模型，出色的完成了抽象任务，在此向Doug Lea致敬。
AQS比较抽象，并且是优化精简的代码，如果一头扎进去，可能会比较容易迷失。本篇只解说CountDownLatch中使用到的共享锁模型。
我们以CountDownLatch第二个例子作为案例来分析一下，一开始，我们创建了一个CountDownLatch实例，
此时，AQS中，状态值state=2，对于 CountDownLatch 来说，state=2表示所有调用await方法的线程都应该阻塞，等到同一个latch被调用两次countDown后才能唤醒沉睡的线程。接着线程3和线程4执行了 await方法，这会的状态图如下:
注意，上面的通知状态是节点的属性，表示该节点出队后，必须唤醒其后续的节点线程。当线程1和线程2分别执行完latch.countDown方法后，会把state值置为0，此时，通过CAS成功置为0的那个线程将会同时承担起唤醒队列中第一个节点线程的任务，从上图可以看出，第一个节点即为线程3，当线程3恢复执行之后，其发现状态值为通知状态，所以会唤醒后续节点，即线程4节点，然后线程3继续做自己的事情，到这里，线程3和线程4都已经被唤醒，CountDownLatch功成身退。
上面的流程，如果落实到代码，把 state置为0的那个线程，会判断head指向节点的状态，如果为通知状态，则唤醒后续节点，即线程3节点，然后head指向线程3节点，head指向的旧节点会被删除掉。当线程3恢复执行后，发现自身为通知状态，又会把head指向线程4节点，然后删除自身节点，并唤醒
线程4。
这里可能读者会有个疑问，线程节点的状态是什么时候设置上去的。其实，一个线程在阻塞之前，就会把它前面的节点设置为通知状态，这样便可以实现链式唤醒机制了。