concurrent
ReentranLock
Condition
子主题
AbstractQueuedSynchronizer
Node<br>每个等待的线程都是一个node<br>
waitStatus:<br>状态: 阻塞,wait, 取消执行 ......
thread: node关联的线程
nextWaiter
state: 可用的资源数量,<br>semphore/CountDownLatch: 可以设置为多个<br>ReentrantLock: 设置为1
CyclicBarrier
CyclicBarrier设置一个总值, 多个线程调用await方法后开始阻塞<br>当总值为0 ,所有线程才能执行
CountDownLatch
设置一个总值, 每次使用减1 , A线程调用await方法, <br>A线程阻塞到 CountDownLatch值为0
Semaphore信号量
设置总值, 每次使用减1, 用完加1
Phaser
ReentrantReadWriteLock
子主题
LockSupport
可以在任何地方暂停一个线程指定时间, 类似wait, 但是不需要在synchronized内执行
CompletableFuture
Future.get方法还是会阻塞, CompletableFeture 可以以回调的方式进行
本质也是交给线程池去执行
还有串行, 并行等线程间的协调功能
ForkJoinPool
任务拆分后汇总, 类似于MapReduce
ConCurrentHashMap
CopyOnWriteArrayList
线程安全的list<br>缺点: 占用内存较多<br> 只能保证数据的最终一致性
ThreadLocal
结论: 可能会造成内存泄漏
引用链: Thread -> ThreadLocalMap -> Entry(ThreadLocal , Value)<br>Entry中的threadLocal是弱引用, 所以Entry可能变成无法使用的数据 Entry(null, value)
如果不使用线程池那么线程销毁之后 引用连也就断裂了, 所有对象都会被回收
如果使用的是线程池, 那么所有对象都无法回收, Entry的key为null导致无法引用, 成了脏数据
ThreadLocal 也有优化, 会去清理key为null的值, 但并不是总能起效
最佳实践: 每次使用完都清空
CAS
变更失败时自旋, <br>比如: AtomicInteger 的 getAndIncrease 第一次失败之后, <br>会重新获取内存的值,然后再相加, 再设置<br>
cas是一组原子命令, 但是不保证可见性,所以需要加volatile<br>比如AtomicInteger的value就加了volatile
Copy-on-writer
在往容器写入的时候, 复制一个原来的容器,往新的容器内写入数据.<br>写入完成之后再将旧的容器的引用指向新的容器
优点: 可以不用加锁<br>缺点: 只能保证数据的最终一致性, <br> 占用内存较多
CopyOnWriteArrayList
CopyOnWriteSet
