多线程相关的知识

多线程的三个特性：原子性，有序性和可见性。

可见性: 一个线程对共享变量的修改，能够及时的被其他线程看到；
原子性: 即不可再分了，不能分为多步操作。比如赋值或者return；
有效性: 有序性是指程序执行的顺序按照代码的先后顺序执行

1 .只有一个线程写，其他都是读。（1.保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。2.禁止进行指令重排序。）用 volatile 原理参考链接
2 . 多个线程写，用 Synchronized
3 .多个线程写+设置超时+自行决定释放，用 ReentranLock
4. 想提高效率，不单单一个线程进入临界区，用并发包，如：ConcurrentHashMap、LinkBlockingQueue、AtomicXXX。 crossoverjie.top/2018/07/23/… www.hangge.com/blog/cache/…
5. 读比写多，用 CopyOnWriteXXX
6. 希望控制线程的并发数量，用 Semaphore 信号量
7. 想让指定线程等待其他线程，用 CountDownLatch
juejin.cn/post/684490… blog.csdn.net/qq_21993785…

Atomic

提供的主要操作有：
增加值并返回新值：int addAndGet(int delta)
加1后返回新值：int incrementAndGet()
获取当前值：int get()
用CAS方式设置：int compareAndSet(int expect, int update)
使用java.util.concurrent.atomic提供的原子操作可以简化多线程编程：
原子操作实现了无锁的线程安全；
适用于计数器，累加器等。
Atomic类是通过无锁（lock-free）的方式实现的线程安全（thread-safe）访问。
它的主要原理是利用了CAS：Compare and Set。CAS 被认为是一种乐观锁。
（如果这把锁始终不能释放，其他线程会一直阻塞等待下去，此时可以认为是悲观。乐观锁，会以一种更加乐观的态度对待事情，认为自己可以操作成功。当多个线程操作同一个共享资源时，仅能有一个线程同一时间获得锁成功，在乐观锁中，其他线程发现自己无法成功获得锁，并不会像悲观锁那样阻塞线程，而是直接返回，可以去选择再次重试获得锁，也可以直接退出）
一文彻底搞懂CAS实现原理

Synchronized和Volatile的比较

Synchronized保证内存可见性和操作的原子性
Volatile只能保证内存可见性
Volatile不需要加锁，比Synchronized更轻量级，并不会阻塞线程（volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。）
volatile标记的变量不会被编译器优化,而synchronized标记的变量可以被编译器优化（如编译器重排序的优化）.
volatile是变量修饰符，仅能用于变量，而synchronized是一个方法或块的修饰符。 volatile本质是在告诉JVM当前变量在寄存器中的值是不确定的，使用前，需要先从主存中读取，因此可以实现可见性。而对n=n+1,n++等操作时，volatile关键字将失效，不能起到像synchronized一样的线程同步（原子性）的效果。
内存可见性和原子性：Synchronized和Volatile的比较

CopyOnWriteArrayList:

CopyOnWrite容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。 CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单等场景。CopyOnWriteArrayList读取时不加锁，只是写入、删除、修改时加锁。 CopyOnWrite两个缺点：内存占用问题。因为CopyOnWrite的写时复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存，旧的对象和新写入的对象（注意:在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存）。数据一致性问题。CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。【当执行add或remove操作没完成时，get获取的仍然是旧数组的元素】
CopyOnWriteArrayList原理，优缺点，使用场景

什么是悲观锁和乐观锁？

锁是为了避免自己在修改资源的时候，别人同时在修改，导致同一时间产生两份修改，不知道如何处理的情况而设置的独占资源，避免多个操作同时处理同一资源的技术。乐观锁：默认为，某个线程在自己处理共享资源的时候，不会出现同一时刻来修改此资源的前提，只在处理完毕，最后写入内存的时候，检测是否此资源在之前未被修改。在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS(compare and swap)算法实现。类似于读写锁的读锁就是乐观锁。悲观锁：默认为，某个线程在自己处理共享资源的时候，一定会出现同一时刻来修改此资源，所以刚拿到这个资源就直接加锁，不让其他线程来操作，加锁在逻辑处理之前。类似，synchronized关键字，条件锁，数据库的行锁，表锁等就是悲观锁。

HashMap 多线程死循环问题

HashMap非线程安全，即任一时刻可以有多个线程同时写HashMap，可能会导致数据的不一致。如果需要满足线程安全，可以用Collections的synchronizedMap方法使HashMap具有线程安全的能力，或者使用ConcurrentHashMap

Java内存模型：

Java所有变量都存储在主内存中
每个线程都有自己独立的工作内存，里面保存该线程的使用到的变量副本（该副本就是主内存中该变量的一份拷贝） Java多线程内存可见性：
1. 线程对共享变量的所有操作都必须在自己的工作内存中进行，不能直接在主内存中读写
2. 不同线程之间无法直接访问其他线程工作内存中的变量，线程间变量值的传递需要通过主内存来完成。线程1对共享变量的修改，要想被线程2及时看到，必须经过如下2个过程：
1. 把工作内存1中更新过的共享变量刷新到主内存中
2. 将主内存中最新的共享变量的值更新到工作内存2中 blog.csdn.net/guyuealian/…
版本结构区别

JDK1.8|HashMap是数组+链表+红黑树（链表长度大于8时转化为红黑树）|
HashMap就是使用哈希表来存储的。哈希表为解决冲突，可以采用开放地址法和链地址法等来解决问题，Java中HashMap采用了链地址法。链地址法，简单来说，就是数组加链表的结合。在每个数组元素上都一个链表结构，当数据被Hash后，得到数组下标，把数据放在对应下标元素的链表上。

tech.meituan.com/2016/06/24/…
www.jianshu.com/p/8324a3457…

ReentranLock

通常获取锁的方式如下：

在Java的ReentrantLock构造函数中提供了两种锁：创建公平锁和非公平锁（默认）：

/**
 * 默认构造方法，非公平锁
 */
public ReentrantLock() {
    sync = new NonfairSync();
}

/**
 * true公平锁，false非公平锁
 * @param fair
 */
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

公平锁保证一个阻塞的线程最终能够获得锁，因为是有序的，所以总是可以按照请求的顺序获得锁。非公平锁意味着后请求锁的线程可能在其前面排列的休眠线程恢复前拿到锁，这样就有可能提高并发的性能。这是因为通常情况下挂起的线程重新开始与它真正开始运行，二者之间会产生严重的延时。因此非公平锁就可以利用这段时间完成操作。这是非公平锁在某些时候比公平锁性能要好的原因之一。锁Lock分为“公平锁”和“非公平锁”，公平锁表示线程获取锁的顺序是按照线程加锁的顺序来分配的，即先来先得的FIFO先进先出顺序。而非公平锁就是一种获取锁的抢占机制，是随机获得锁的，和公平锁不一样的就是先来的不一定先得到锁，这个方式可能造成某些线程一直拿不到锁，结果也就是不公平的了。

ReentrantLock 与 synchronized 的比较：

相同：ReentrantLock提供了synchronized类似的功能和内存语义。不同：

与synchronized相比，ReentrantLock提供了更多，更加全面的功能，具备更强的扩展性。例如：时间锁等候，可中断锁等候，锁投票。
ReentrantLock还提供了条件Condition，对线程的等待、唤醒操作更加详细和灵活，所以在多个条件变量和高度竞争锁的地方，ReentrantLock更加适合（下面会阐述Condition）。
ReentrantLock提供了可轮询的锁请求。它会尝试着去获取锁，如果成功则继续，否则可以等到下次运行时处理，而synchronized则一旦进入锁请求要么成功，要么一直阻塞，所以相比synchronized而言，ReentrantLock会不容易产生死锁些。
ReentrantLock支持更加灵活的同步代码块，但是使用synchronized时，只能在同一个synchronized块结构中获取和释放。注：ReentrantLock的锁释放一定要在finally中处理，否则可能会产生严重的后果。
ReentrantLock支持中断处理，且性能较synchronized会好些。 Java多线程之ReentrantLock与Condition

重入锁：

ReentrantLock是一个重入锁，可以支持一个线程对资源重复加锁，他还支持公平加锁和非公平加锁。synchronized关键字也隐式的支持重进入，比如一个synchronized修饰的递归方法，在方法执行时，执行线程在获取了锁之后仍能连续多次地获得该锁。ReentrantLock虽然没能像synchronized关键字一样支持隐式的重进入，但是在调用lock()方法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。

实现锁重进入：

重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞线程再次获取锁：锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。锁的最终释放：线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。

ReadWriteLock

只允许一个线程写入（其他线程既不能写入也不能读取）；没有写入时，多个线程允许同时读（提高性能）

public class Counter {
    private final ReadWriteLock rwlock = new ReentrantReadWriteLock();
    private final Lock rlock = rwlock.readLock();
    private final Lock wlock = rwlock.writeLock();
    private int[] counts = new int[10];
 
    public void inc(int index) {
        wlock.lock(); // 加写锁
        try {
            counts[index] += 1;
        } finally {
            wlock.unlock(); // 释放写锁
        }
    }

    public int[] get() {
        rlock.lock(); // 加读锁
        try {
            return Arrays.copyOf(counts, counts.length);
        } finally {
            rlock.unlock(); // 释放读锁
        }
    }
}

例如一个论坛的帖子，回复可以看做写入操作，它是不频繁的，但是，浏览可以看做读取操作，是非常频繁的，这种情况就可以使用 ReadWriteLock。
小结：使用ReadWriteLock可以提高读取效率： ReadWriteLock只允许一个线程写入； ReadWriteLock允许多个线程在没有写入时同时读取； ReadWriteLock适合读多写少的场景。
使用ReadWriteLock

Condition类：

Condition类能实现synchronized和wait、notify搭配的功能，另外比后者更灵活，Condition可以实现多路通知功能，也就是在一个Lock对象里可以创建多个Condition（即对象监视器）实例，线程对象可以注册在指定的Condition中，从而可以有选择的进行线程通知，在调度线程上更加灵活。而synchronized就相当于整个Lock对象中只有一个单一的Condition对象，所有的线程都注册在这个对象上。线程开始notifyAll时，需要通知所有的WAITING线程，没有选择权，会有相当大的效率问题。

1、Condition是个接口，基本的方法就是await()和signal()方法。 2、Condition依赖于Lock接口，生成一个Condition的基本代码是lock.newCondition()，参考下图。

3、调用Condition的await()和signal()方法，都必须在lock保护之内，就是说必须在lock.lock()和lock.unlock之间才可以使用。
4、Conditon中的await()对应Object的wait()，Condition中的signal()对应Object的notify()，Condition中的signalAll()对应Object的notifyAll()。使用Condition来实现等待/唤醒制定线程；它实现生产者消费者模式；可以用它来实现顺序执行线程；
Java多线程之ReentrantLock与Condition

谈谈线程死锁，如何有效的避免线程死锁？

死锁产生的必要条件:

产生死锁必须同时满足以下四个条件，只要其中任一条件不成立，死锁就不会发生。

互斥条件：进程要求对所分配的资源（如打印机）进行排他性控制，即在一段时间内某资源仅为一个进程所占有。此时若有其他进程请求该资源，则请求进程只能等待。
不剥夺条件：进程所获得的资源在未使用完毕之前，不能被其他进程强行夺走，即只能由获得该资源的进程自己来释放（只能是主动释放)。
请求和保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有，此时请求进程被阻塞，但对自己已获得的资源保持不放。
循环等待条件：存在一种进程资源的循环等待链，链中每一个进程已获得的资源同时被链中下一个进程所请求。

如何避免死锁:

加锁顺序: 线程按照一定的顺序加锁,按照顺序加锁是一种有效的死锁预防机制。但是，这种方式需要你事先知道所有可能会用到的锁(译者注：并对这些锁做适当的排序)，但总有些时候是无法预知的。
加锁时限: 线程尝试获取锁的时候加上一定的时限，超过时限则放弃对该锁的请求，并释放自己占有的锁.如果有非常多的线程同一时间去竞争同一批资源，就算有超时和回退机制，还是可能会导致这些线程重复地尝试但却始终得不到锁死锁检测:每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。线程A等待线程B，线程B等待线程C，线程C等待线程D，线程D又在等待线程A。线程A为了检测死锁，它需要递进地检测所有被B请求的锁。从线程B所请求的锁开始，线程A找到了线程C，然后又找到了线程D，发现线程D请求的锁被线程A自己持有着。这是它就知道发生了死锁。

当检测出死锁时，这些线程该做些什么呢？ :一个可行的做法是释放所有锁，回退，并且等待一段随机的时间后重试。这个和简单的加锁超时类似，不一样的是只有死锁已经发生了才回退，而不会是因为加锁的请求超时了。虽然有回退和等待，但是如果有大量的线程竞争同一批锁，它们还是会重复地死锁（原因同超时类似，不能从根本上减轻竞争）。一个更好的方案是给这些线程设置优先级，让一个（或几个）线程回退，剩下的线程就像没发生死锁一样继续保持着它们需要的锁。如果赋予这些线程的优先级是固定不变的，同一批线程总是会拥有更高的优先级。为避免这个问题，可以在死锁发生的时候设置随机的优先级。

线程池

获取这五种线程池，通过Executors的工厂方法来获取：

 ExecutorService fixedThreadPool = Executors.newFixedThreadPool(5);
 ExecutorService singleThreadPool = Executors.newSingleThreadExecutor();
 ExecutorService cachedThreadPool = Executors.newCachedThreadPool();
 ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(5);
 ScheduledExecutorService singleThreadScheduledPool = Executors.newSingleThreadScheduledExecutor();

1. newFixedThreadPool() ：

作用： 该方法返回一个固定线程数量的线程池，该线程池中的线程数量始终不变，即不会再创建新的线程，也不会销毁已经创建好的线程，自始自终都是那几个固定的线程在工作，所以该线程池可以控制线程的最大并发数。
栗子： 假如有一个新任务提交时，线程池中如果有空闲的线程则立即使用空闲线程来处理任务，如果没有，则会把这个新任务存在一个任务队列中，一旦有线程空闲了，则按FIFO方式处理任务队列中的任务。

2. newCachedThreadPool() ：

作用： 该方法返回一个可以根据实际情况调整线程池中线程的数量的线程池。即该线程池中的线程数量不确定，是根据实际情况动态调整的。
栗子： 假如该线程池中的所有线程都正在工作，而此时有新任务提交，那么将会创建新的线程去处理该任务，而此时假如之前有一些线程完成了任务，现在又有新任务提交，那么将不会创建新线程去处理，而是复用空闲的线程去处理新任务。那么此时有人有疑问了，那这样来说该线程池的线程岂不是会越集越多？其实并不会，因为线程池中的线程都有一个“保持活动时间”的参数，通过配置它，如果线程池中的空闲线程的空闲时间超过该“保存活动时间”则立刻停止该线程，而该线程池默认的“保持活动时间”为60s。

3. newSingleThreadExecutor() ：

作用： 该方法返回一个只有一个线程的线程池，即每次只能执行一个线程任务，多余的任务会保存到一个任务队列中，等待这一个线程空闲，当这个线程空闲了再按FIFO方式顺序执行任务队列中的任务。

4. newScheduledThreadPool() ：

作用： 该方法返回一个可以控制线程池内线程定时或周期性执行某任务的线程池。

5. newSingleThreadScheduledExecutor() ：

作用： 该方法返回一个可以控制线程池内线程定时或周期性执行某任务的线程池。只不过和上面的区别是该线程池大小为1，而上面的可以指定线程池的大小。
线程池底部都是创建一个ThreadPoolExecutor对

public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {//...}

我们可以看到它构造方法的参数比较多，有七个，下面一一来说明这些参数的作用：

corePoolSize：线程池中的核心线程数量
maximumPoolSize：线程池中的最大线程数量
keepAliveTime：这个就是上面说到的“保持活动时间“，上面只是大概说明了一下它的作用，不过它起作用必须在一个前提下，   
就是当线程池中的线程数量超过了corePoolSize时，它表示多余的空闲线程的存活时间，    
即：多余的空闲线程在超过keepAliveTime时间内没有任务的话则被销毁。而这个主要应用在缓存线程池中
unit：它是一个枚举类型，表示keepAliveTime的单位，常用的如：TimeUnit.SECONDS（秒）、TimeUnit.MILLISECONDS（毫秒）
workQueue：任务队列，主要用来存储已经提交但未被执行的任务，不同的线程池采用的排队策略不一样，稍后再讲
threadFactory：线程工厂，用来创建线程池中的线程，通常用默认的即可
handler：通常叫做拒绝策略，1、在线程池已经关闭的情况下 2、任务太多导致最大线程数和任务队列已经饱和，无法再接收新的任务 。
在上面两种情况下，只要满足其中一种时，在使用execute()来提交新的任务时将会拒绝，而默认的拒绝策略是抛一个RejectedExecutionException异常

自定义优先级线程池，暂停线程池
 github.com/LQG24/DataS…

线程的几种状态

    /**
     * 初始(NEW)：新创建了一个线程对象，但还没有调用start()方法。
     */
    NEW,
 
    /**
     * 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。
     * 线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。
     * 该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，
     * 此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）。
     */
    RUNNABLE,
 
    /**
     * 阻塞(BLOCKED)：表示线程阻塞于锁。
     */
    BLOCKED,
 
    /**
     * 等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。
     */
    WAITING,
 
    /**
     * 超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。
     */
    TIMED_WAITING,
 
    /**
     * 终止(TERMINATED)：表示该线程已经执行完毕。
     */
    TERMINATED;
}

并发队列ConcurrentLinkedQueue和阻塞队列LinkedBlockingQueue使用场景总结

适用阻塞队列的好处：多线程操作共同的队列时不需要额外的同步，另外就是队列会自动平衡负载，即那边（生产与消费两边）处理快了就会被阻塞掉，从而减少两边的处理速度差距
当许多线程共享访问一个公共 collection 时，ConcurrentLinkedQueue 是一个恰当的选择。
LinkedBlockingQueue 多用于任务队列
ConcurrentLinkedQueue 多用于消息队列

单生产者，单消费者用 LinkedBlockingqueue
多生产者，单消费者   用 LinkedBlockingqueue
单生产者，多消费者   用 ConcurrentLinkedQueue
多生产者，多消费者   用 ConcurrentLinkedQueue
并发包中的ConcurrentLinkedQueue和LinkedBlockingQueue有什么区别

ConcurrentHashMap并发的HashMap

ConcurrentHashMap是一个二级哈希表。在一个总的哈希表下面，有若干个子哈希表。

ConcurrentHashMap优势是才用锁分段技术，每一个Segment就好比一个自治区，读写操作高度自治，Segment之间互不影响。

ConcurrentHashMap读写过程：

Get方法：

1.为输入的Key做Hash运算，得到hash值。
2.通过hash值，定位到对应的Segment对象
3.再次通过hash值，定位到Segment当中数组的具体位置。

Put方法：

1.为输入的Key做Hash运算，得到hash值。
2.通过hash值，定位到对应的Segment对象
3.获取可重入锁
4.再次通过hash值，定位到Segment当中数组的具体位置。
5.插入或覆盖HashEntry对象。
6.释放锁。

统计ConcurrentHashMap的size个数，怎么解决一致性问题？

ConcurrentHashMap的Size方法是一个嵌套循环，大体逻辑如下：
1.遍历所有的Segment。
2.把Segment的元素数量累加起来。
3.把Segment的修改次数累加起来。
4.判断所有Segment的总修改次数是否大于上一次的总修改次数。如果大于，说明统计过程中有修改，重新统计，尝试次数+1；如果不是。说明没有修改，统计结束。
5.如果尝试次数超过阈值，则对每一个Segment加锁，再重新统计。
6.再次判断所有Segment的总修改次数是否大于上一次的总修改次数。由于已经加锁，次数一定和上次相等。
7.释放锁，统计结束。

    // Try a few times to get accurate count. On failure due to
   // continuous async changes in table, resort to locking.
   final Segment<K,V>[] segments = this.segments;
    int size;
    boolean overflow; // true if size overflows 32 bits
    long sum;         // sum of modCounts
    long last = 0L;   // previous sum
    int retries = -1; // first iteration isn't retry
    try {
        for (;;) {
            if (retries++ == RETRIES_BEFORE_LOCK) {
                for (int j = 0; j < segments.length; ++j)
                    ensureSegment(j).lock(); // force creation
            }
            sum = 0L;
            size = 0;
            overflow = false;
            for (int j = 0; j < segments.length; ++j) {
                Segment<K,V> seg = segmentAt(segments, j);
                if (seg != null) {
                    sum += seg.modCount;
                    int c = seg.count;
                    if (c < 0 || (size += c) < 0)
                        overflow = true;
                }
            }
            if (sum == last)
                break;
            last = sum;
        }
    } finally {
        if (retries > RETRIES_BEFORE_LOCK) {
            for (int j = 0; j < segments.length; ++j)
                segmentAt(segments, j).unlock();
        }
    }
    return overflow ? Integer.MAX_VALUE : size;
}

为什么这样设计呢？这种思想和乐观锁悲观锁的思想如出一辙。

为了尽量不锁住所有Segment，首先乐观地假设Size过程中不会有修改。当尝试一定次数，才无奈转为悲观锁，锁住所有Segment保证强一致性。
什么是ConcurrentHashMap？

HashMap? ConcurrentHashMap? 相信看完这篇没人能难住你