qq_42861526的博客

多个线程对hashmap进行扩容时需要将原有数据转移到新的table数组中，这个过程中会重新计算每个元素对应的数组下标从而改变元素的next指针，而另一个线程重复对该链表进行迁移时可能会导致循环链表的产生二、JDK8-ConcurrentHashMap额外提一句，JUC包下提供了许多并发安全的容器，它们的前缀大概有如下几种，我们来分别讨论它们的特性。包含三类关键词：Blocking、CopyOnWrite、Concurrent构造器可以看到实现了懒惰初始化，在构造方法中仅仅计算了 table

state：表示当前锁的状态，前16位为写锁标识，后16位为读锁标识，0表示无锁，state的值表示锁重入的次数Node：若当前线程获取锁失败，则会将其关联到一个新的Node节点添加到阻塞队列中写锁上锁释放读锁上锁解锁tryReleaseShareddoReleaseShared：唤醒后继节点

注意：等待队列的head指向的要么是正在运行的线程所在节点，要么是dummy结点(不含线程)简单说就是不可打断模式下，若阻塞的线程被打断会再次进入阻塞队列。非公平性具体体现在acquireQueued方法中。每个条件变量都维护了一条等待队列，如图所示。**release(AQS已实现)

LongAdder通过使用多个cell分摊并发压力提高累加器性能，并且用@Contended注解修饰Cell对象，使其能够独占缓存行，解决了缓存行伪共享的问题。而AutomicInteger内部只用一个变量用来表示当前值，在高并发下多个线程争抢该变量性能损耗较大。

在实际业务场景中，我们大概率会使用Future的方式来得到该结果，但Future必须是当t2线程执行完返回结果后才能在t1线程获取到。但我们可能会碰到t2线程业务很重，而t1线程只需要等待t2完成某一个操作时就能得到该结果继续往下执行，我们该怎么办呢？

大家对于synchronized应该不陌生，在我们实际业务中经常需要书写同步代码块来保证线程安全性，而synchronized便是我们常用的一个加锁方式。那么问题来了，在高并发的情况下，synchronized是如何保证线程安全的呢？