读写锁跟互斥锁类似，也是申请锁的时候，如果不能得到满足则阻塞，但读写锁跟互斥锁也有不同，读写锁有3个状态：已加读锁状态已加写锁状态未加锁状态对应3个状态，读写锁有3个接口：加读锁，加写锁，解锁：加读锁：如果读写锁处于已加写锁状态，则申请锁的线程阻塞；否则把锁设置为已加读锁状态并成功返回加写锁：如果读

插入元素的时候的加锁操作插入元素的时候会通过tryLock尝试获取锁，如果获取失败那么会进入自旋状态，直到自旋的次数达到阈值，这时候会通过lock方法进行阻塞当前线程。扩容的时候的lastRun是什么意思lastRun代表着这个链表从最后的一个节点开始往上直到计算idx不一样的为止。这个目的是为了加

如果是单个线程，在 CPU 调用之后，那么它基本上是不会被调度出去的。如果可运行的线程数远大于 CPU 数量，那么操作系统最终会将某个正在运行的线程调度出来，从而使其它线程能够使用 CPU ，这就会导致上下文切换。还有，在多线程中如果使用了竞争锁，当线程由于等待竞争锁而被阻塞时，JVM 通常会将这个

前言并发场景下通常会使用 AtomicLong 原子类进行计数等操作，在 JDK1.8 中提供了 LongAdder 来实现类似功能。相对于 AtomicLong ，LongAdder 有着更高的性能，可以完全替代 AtomicLong 的计数操作。下面我们先对 AtomicLong 简单介绍，然后

前言ArrayList 是一个非线程安全集合，需要使用方自行处理线程安全问题，或者使用 Collections.synchronizedList 包装。从 JDK 1.5 开始 JUC 中提供了使用写时复制机制实现的并发容器 CopyOnWriteArrayList。概述CopyOnWriteArr

使用场景读写锁使用场景读写锁、不加锁之间的区别共享锁和不加锁的区别?读写锁是读写和写写间互斥，读读间不冲突，少写多读的场景用读写锁比较好。

在实际工作中，我们需要根据任务类型的不同选择对应的策略。CPU 密集型任务首先，我们来看 CPU 密集型任务，比如加密、解密、压缩、计算等一系列需要大量耗费 CPU 资源的任务。对于这样的任务最佳的线程数为 CPU 核心数的 1~2 倍，如果设置过多的线程数，实际上并不会起到很好的效果。此时假设我们

二叉堆算法二叉堆算法文章

线程池拒绝策略时机第一种情况是当我们调用 shutdown 等方法关闭线程池后，即便此时可能线程池内部依然有没执行完的任务正在执行，但是由于线程池已经关闭，此时如果再向线程池内提交任务，就会遭到拒绝。第二种情况是线程池没有能力继续处理新提交的任务，也就是工作已经非常饱和的时候。线程池拒绝策略第一种拒

线程状态