并发下的容器（ArrayList、HashMap）安全问题

最近在做项目的是后遇到了并发安全问题，当多个线程操作ArrayList、HashMap等数据结构时造成了数据不一致，或者莫名其妙的异常，最后查阅资料发现是本身这些数据结构的并发安全问题导致的。

1.ArrayList

我们知道ArrayList底层仍是数组模拟：

• add操作实际上是数组赋值，然后指针++操作
• 另外当容量超过初始容量时会自动进行容量扩展，底层实现即通过copy方式将现在的数组copy到更大的数组上，然后返回。

而正是上面这两个操作造成了并发安全问题，考虑两个线程A和B和共享变量ArrayList——C，当C的容量还剩下1，此时A执行add操作，但是还未完成，此时cpu被B获得，此时B也执行了add操作，由于A还未完成，此时在B看来容量还满足，于是最终B完成了add操作，并执行容量扩展操作，但是此时又被A占用了CPU，而此时A再度执行接下来的add操作，于是导致了数组越界错误（因为B已经导致了指针++，但是容量还没来得及扩展）。
另外由于，add操作实际上是赋值操作，当A和B都处于同一个数组指针位置的时候，就会造成赋值覆盖问题，导致数据不一致。

——解决方案，用线程安全的Vector替代。

2.HashMap

HashMap是基于哈希表的 Map 接口的实现。此实现提供所有可选的映射操作，并允许使用 null 值和 null 键。（除了非同步和允许使用 null 之外，HashMap 类与 Hashtable 大致相同。）此类不保证映射的顺序，特别是它不保证该顺序恒久不变。

• 我们可以看到其put操作，实际上也是在hash表上进行赋值操作，而对于对多线程而言，无疑这就会造成对同一个hash索引被重复赋值，造成某个线程的put被覆盖掉（即消失）。所以对于并发的put操作，很有可能最终的数据量不一致。
• 另外resize在多线程环境下，可能产生条件竞争。因为如果两个线程都发现HashMap需要重新调整大小了，它们会同时试着调整大小。在调整大小的过程中，存储在链表中的元素的次序会反过来，因为移动到新的bucket位置的时候，HashMap并不会将元素放在链表的尾部，而是放在头部，这是为了避免尾部遍历(tail traversing，否则针对key的hashcode相同的Entry每次添加还要定位到尾节点)。如果条件竞争发生了，可能出现环形链表。之后当我们get(key)操作时，就有可能发生死循环。

那是不是我们需要使用HashTable这个安全的类呢，自然不是，因为它使用synchronized来保证线程安全，会锁住整个哈希表。在线程竞争激烈的情况下效率非常低下，当一个线程访问HashTable的同步方法时，其它线程访问HashTable的同步方法只能进入阻塞或轮询状态。
对于提高并发性能而言，我们需要的就是尽肯能将锁用在最细的粒度上满足业务要求，而对于HashMap而言，显然对于读操作get是可以并发执行的，不需要加锁。（Java7） 其次对于写put而言，也并不需要锁住整个表，我们可以进一步在内部将表划分成为segment，在put时先尝试2次通过不锁住segment的方式来统计各个segment大小，如果统计过程中，容器的count发生了变化，再采用加锁的方式统计所有segment的大小(put、remove和clear操作元素前都会将modCount进行加1，所以可以通过在统计前后比较modCount是否发生变化来得知容器大小是否发生了变化)，如果count没有发生变化，说明此操作不会有并发安全问题。

使用了不同于传统集合的快速失败迭代器的另外一种迭代方式，我们称为 弱一致迭代器 。在这种迭代方式中，当iterator被创建后集合再发生改变就不再是抛出ConcurrentModificationException，取而代之是在改变时new新的数据从而不影响原有的数据，iterator完成后再将头指针替换为新的数据，这样iterator线程可以使用原来老的数据，而写线程也可以并发的完成改变。更重要的，这保证了多个线程并发执行的连续性和扩展性，是性能提升的关键。

上面的设计思路就实现了细化锁的目的。而这正是ConcurrentHashMap的实现原理。
每次get/put操作都会通过hash算法定位到一个segment，然后再通过hash算法定位到具体的entry。
get操作是不需要加锁的，因为get方法里将要使用的共享变量都定义成了volatile。

定义成volatile的变量（可视为一个读写锁变量），能够在线程之间保持可见性，能够被多线程同时读，并且保证不会读到过期的值，但是只能被单线程写（有一种情况可以被多线程写，就是写入的值不依赖于原值，像直接set值就可以，而i++这样的操作就是非线程安全的）。