手撸架构，并发编程 面试123问
| 技术栈 | 传送门 |
| JAVA 基础 | 手撸架构，Java基础面试100问_vincent-CSDN博客 |
| JAVA 集合 | 手撸架构，JAVA集合面试60问_vincent-CSDN博客 |
| JVM 虚拟机 | 手撸架构，JVM面试30问_vincent-CSDN博客 |
| 并发编程 | 手撸架构，并发编程面试123问_vincent-CSDN博客 |
| Spring | 手撸架构，Spring面试63问_vincent-CSDN博客 |
| Spring cloud | 手撸架构，Spring cloud面试45问_vincent-CSDN博客 |
| SpringBoot | 手撸面试，Spring Boot面试41问_vincent-CSDN博客 |
| Netty 与 RPC | 手撸架构，Netty 与 RPC面试48问_vincent-CSDN博客 |
| Doubo | 手撸架构，Dubbo面试49问_vincent-CSDN博客 |
| Redis | 手撸架构，Redis面试41问_vincent-CSDN博客 |
| Zookeeper | 手撸架构，Zookeeper面试27问_vincent-CSDN博客 |
| Mysql | 手撸架构，Mysql 面试126问_vincent-CSDN博客 |
| MyBatis | 手撸架构，MyBatis面试42问_vincent-CSDN博客 |
| MongoDB | 手撸架构，MongDB 面试50问_vincent-CSDN博客 |
| Elasticsearch | 手撸架构，Elasticsearch 面试25问_vincent-CSDN博客 |
| RabbitMQ | 手撸架构，RabbitMQ 面试49问_vincent-CSDN博客 |
| Kafka | 手撸架构，Kafka 面试42问_vincent-CSDN博客 |
| Docker | 手撸架构，Docker 面试25问_vincent-CSDN博客 |
| Nginx | 手撸架构，Nginx 面试40问_vincent-CSDN博客 |
| 算法 | 常用排序算法总结（1）-- 比较排序_vincent-CSDN博客_比较排序 常用排序算法总结（2）-- 非比较排序算法_vincent-CSDN博客_非比较排序的算法有 |
| 分布式事务 | 分布式事务解决方案(总览)_vincent-CSDN博客 |
| HTTP | 太厉害了，终于有人能把TCP/IP 协议讲的明明白白了_vincent-CSDN博客_tcp和ip |
并发编程的优缺点
优点：
充分利用多核CPU的计算能力：通过并发编程的形式可以将多核CPU的计算能力发挥到极致，性能得到提升
方便进行业务拆分，提升系统并发能力和性能
缺点：
a.上下文切换，要存储当前状态，加载状态，耗时。
尽量不使用锁，导致竞争锁的上下文切换(CAS);
最少使用线程，避免线程浪费等待。
b.死锁，锁没法释放，导致阻塞的线程一直阻塞。
避免一个线程获得多个锁。
线程间加锁顺序尽量一致。
使用定时锁
同步异步
指调用方法，调动同步，必须阻塞等待其执行结束，才能接着往后执行
调用异步，不必等待调用方法返回结果，继续往后执行代码
并行并发
并发：一个CPU，同一时刻，只有一个线程同时运行。
并行：多个CPU，同一时刻，多个线程同时运行。
阻塞和非阻塞
阻塞：只线程间的相互影响，某个线程获得了临界区资源，其他相乘想要获取，就必须等待阻塞其释放才行。
非阻塞：没有线程能阻塞其他线程，所有线程尝试向后执行。
临区界
表示一种公共资源。可以被多个线程获取，一旦资源被某个线程占有，其他线程必须等待。
线程与进程的区别
线程具有许多传统进程所具有的特征，故又称为轻型进程(Light—Weight Process)或进程元；而把传统的进程称为重型进程(Heavy—Weight Process)。在引入了线程的操作系统中，通常一个进程都有若干个线程，至少包含一个线程。
根本区别：进程是操作系统资源分配的基本单位，而线程是处理器任务调度和执行的基本单位。
资源开销和内存分配：每个进程都有独立的代码和数据空间（程序上下文），进程之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小。
包含关系：线程是进程的一部分。一个进程至少有一个线程，一个进程可以运行多个线程。
影响关系：一个进程崩溃后，在保护模式下不会对其他进程产生影响，但是一个线程崩溃整个进程都死掉。所以多进程要比多线程健壮。
执行过程：每个独立的进程有程序入口、顺序执行序列和程序出口。线程不能独立执行，必须依存在进程中，由进程提供多个线程执行控制，两者均可并发执行。
什么是多线程中的上下文切换
多线程会共同使用一组计算机上的CPU，而线程数大于给程序分配的CPU数量时，为了让各个线程都有执行的机会，就需要轮转使用CPU。不同的线程切换使用CPU发生的切换数据等就是上下文切换
并发编程三要素（线程的安全性问题体现在）：
原子性：原子，即一个不可再被分割的颗粒。原子性指的是一个或多个操作要么 全部执行成功要么全部执行失败。
可见性：一个线程对共享变量的修改,另一个线程能够立刻看到。 （synchronized,volatile）
有序性：程序执行的顺序按照代码的先后顺序执行。（处理器可能会对指令进行 重排序）
保证多线程的运行安全
出现线程安全问题的原因：
线程切换带来的原子性问题
缓存导致的可见性问题
编译优化带来的有序性问题
解决办法：
JDK Atomic开头的原子类、synchronized、LOCK，可以解决原子性问题
synchronized、volatile、LOCK，可以解决可见性问题
Happens-Before 规则可以解决有序性问题
在java中守护线程和本地线程区别
java中的线程分为两种：守护线程（Daemon）和用户线程（User）。
任何线程都可以设置为守护线程和用户线程，通过方法Thread.setDaemon(bool on)；true则把该线程设置为守护线程，反之则为用户线程。Thread.setDaemon()必须在Thread.start()之前调用，否则运行时会抛出异常。
守护线程（Daemon）的意义：
只要当前JVM实例中尚存在任何一个非守护线程没有结束，守护线程就全部工作；只有当最后一个非守护线程结束时，守护线程随着JVM一同结束工作。
Daemon的作用是为其他线程的运行提供便利服务，守护线程最典型的应用就是 GC (垃圾回收器)，它就是一个很称职的守护者。
两者的区别：
唯一的区别是判断虚拟机(JVM)何时离开，Daemon是为其他线程提供服务，如果全部的User Thread已经撤离，Daemon 没有可服务的线程，JVM撤离。也可以理解为守护线程是JVM自动创建的线程（但不一定），用户线程是程序创建的线程；比如JVM的垃圾回收线程是一个守护线程，当所有线程已经撤离，不再产生垃圾，守护线程自然就没事可干了，当垃圾回收线程是Java虚拟机上仅剩的线程时，Java虚拟机会自动离开。
扩展：Thread Dump打印出来的线程信息，含有daemon字样的线程即为守护进程，可能会有：服务守护进程、编译守护进程、windows下的监听Ctrl+break的守护进程、Finalizer守护进程、引用处理守护进程、GC守护进程。
注意事项：
setDaemon(true)必须在start()方法前执行，否则会抛出 IllegalThreadStateException 异常
在守护线程中产生的新线程也是守护线程
不是所有的任务都可以分配给守护线程来执行，比如读写操作或者计算逻辑
守护 (Daemon) 线程中不能依靠 finally 块来确保执行关闭或清理资源的逻辑。因为一旦所有用户线程都结束运行，守护线程会随 JVM 一起结束工作，所以守护 (Daemon) 线程中的 finally 语句块可能无法被执行。
死锁与活锁的区别，死锁与饥饿的区别
死锁：是指两个或两个以上的进程（或线程）在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
产生死锁的必要条件：
1. 互斥条件：所谓互斥就是进程在某一时间内独占资源。
2. 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
3. 不剥夺条件:进程已获得资源，在末使用完之前，不能强行剥夺。
4. 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
活锁：任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试，失败，尝试，失败。
活锁和死锁的区别在于，处于活锁的实体是在不断的改变状态，所谓的“活”， 而处于死锁的实体表现为等待；活锁有可能自行解开，死锁则不能。
饥饿：一个或者多个线程因为种种原因无法获得所需要的资源，导致一直无法执行的状态。
Java中导致饥饿的原因：
- 高优先级线程吞噬所有的低优先级线程的CPU时间。
- 线程被永久堵塞在一个等待进入同步块的状态，因为其他线程总是能在它之前持续地对该同步块进行访问。
- 线程在等待一个本身也处于永久等待完成的对象(比如调用这个对象的wait方法)，因为其他线程总是被持续地获得唤醒。
避免线程死锁
我们只要破坏产生死锁的四个条件中的其中一个就可以了。
破坏互斥条件
这个条件我们没有办法破坏，因为我们用锁本来就是想让他们互斥的（临界资源需要互斥访问）。
破坏请求与保持条件
一次性申请所有的资源，会降低并发能力，一般不破坏请求与保持条件。
破坏不剥夺条件
占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。
破坏循环等待条件
靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。
Java中用到的线程调度算法
计算机通常只有一个CPU,在任意时刻只能执行一条机器指令,每个线程只有获得CPU的使用权才能执行指令.所谓多线程的并发运行,其实是指从宏观上看,各个线程轮流获得CPU的使用权,分别执行各自的任务.在运行池中,会有多个处于就绪状态的线程在等待CPU,JAVA虚拟机的一项任务就是负责线程的调度,线程调度是指按照特定机制为多个线程分配CPU的使用权.
有两种调度模型：分时调度模型和抢占式调度模型。
分时调度模型是指让所有的线程轮流获得cpu的使用权,并且平均分配每个线程占用的CPU的时间片这个也比较好理解。
java虚拟机采用抢占式调度模型，是指优先让可运行池中优先级高的线程占用CPU，如果可运行池中的线程优先级相同，那么就随机选择一个线程，使其占用CPU。处于运行状态的线程会一直运行，直至它不得不放弃CPU。
进程调度算法
- 先来先服务：先来后到
- 时间片轮转：先来先服务，但是只运行一个时间片（如100ms）
- 短作业优先 ：从后备队列中选择一个或若干个估计运行时间最短的作业，将它们调入内存运行
- 最短剩余时间：选择预期剩余时间最短的进程
- 高响应比：R=(w+s)/s （R为响应比，w为等待处理的时间，s为预计的服务时间）
- 优先级：从后备作业队列中选择优先级最髙的一个或几个作业，将它们调入内存
- 多级反馈队列：既能使高优先级的作业得到响应又能使短作业（进程）迅速完成
什么是线程组，为什么在Java中不推荐使用
ThreadGroup类，可以把线程归属到某一个线程组中，线程组中可以有线程对象，也可以有线程组，组中还可以有线程，这样的组织结构有点类似于树的形式。
为什么不推荐使用？因为使用有很多的安全隐患吧，没有具体追究，如果需要使用，推荐使用线程池。
线程安全
线程安全就是说多线程访问同一代码，不会产生不确定的结果。
在多线程环境中，当各线程不共享数据的时候，即都是私有（private）成员，那么一定是线程安全的。但这种情况并不多见，在多数情况下需要共享数据，这时就需要进行适当的同步控制了。
线程安全一般都涉及到synchronized， 就是一段代码同时只能有一个线程来操作 不然中间过程可能会产生不可预制的结果。
如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。
servlet 是线程安全吗
Servlet 不是线程安全的，servlet 是单实例多线程的，当多个线程同时访问同一个
方法，是不能保证共享变量的线程安全性的。
线程的生命周期及五种基本状态
新建状态（New）
用new语句创建的线程处于新建状态，此时它和其他Java对象一样，仅仅在堆区中被分配了内存。
就绪状态（Runnable）
当一个线程对象创建后，其他线程调用它的start()方法，该线程就进入就绪状态，Java虚拟机会为它创建方法调用栈和程序计数器。处于这个状态的线程位于可运行池中，等待获得CPU的使用权。
运行状态（Running）
处于这个状态的线程占用CPU，执行程序代码。只有处于就绪状态的线程才有机会转到运行状态。
阻塞状态（Blocked）
阻塞状态是指线程因为某些原因放弃CPU，暂时停止运行。当线程处于阻塞状态时，Java虚拟机不会给线程分配CPU。直到线程重新进入就绪状态，它才有机会转到运行状态。
阻塞状态可分为以下3种：
位于对象等待池中的阻塞状态（Blocked in object’s wait pool）：当线程处于运行状态时，如果执行了某个对象的wait()方法，Java虚拟机就会把线程放到这个对象的等待池中，这涉及到“线程通信”的内容。
位于对象锁池中的阻塞状态（Blocked in object’s lock pool）：当线程处于运行状态时，试图获得某个对象的同步锁时，如果该对象的同步锁已经被其他线程占用，Java虚拟机就会把这个线程放到这个对象的锁池中，这涉及到“线程同步”的内容。
其他阻塞状态（Otherwise Blocked）：当前线程执行了sleep()方法，或者调用了其他线程的join()方法，或者发出了I/O请求时，就会进入这个状态。
死亡状态（Dead）
当线程退出run()方法时，就进入死亡状态，该线程结束生命周期。1
Java规定的线程状态
关于线程生命周期的不同状态
在 Java 5 以后，线程状态被明确定义在其公共内部枚举类型 java.lang.Thread.State 中，分别是：
- 新建（NEW），表示线程被创建出来还没真正启动的状态，可以认为它是个 Java 内部状态。
- 就绪（RUNNABLE），表示该线程已经在 JVM 中执行，当然由于执行需要计算资源，它可能是正在运行，也可能还在等待系统分配给它 CPU 片段，在就绪队列里面排队。
- 在其他一些分析中，会额外区分一种状态 RUNNING，但是从 Java API 的角度，并不能表示出来。
- 阻塞（BLOCKED），阻塞表示线程在等待 Monitor lock。比如，线程试图通过 synchronized 去获取某个锁，但是其他线程已经独占了，那么当前线程就会处于阻塞状态。
- 等待（WAITING），表示正在等待其他线程采取某些操作。一个常见的场景是类似生产者消费者模式，发现任务条件尚未满足，就让当前消费者线程等待（wait），另外的生产者线程去准备任务数据，然后通过类似 notify 等动作，通知消费线程可以继续工作了。Thread.join() 也会令线程进入等待状态。
- 计时等待（TIMED_WAIT），其进入条件和等待状态类似，但是调用的是存在超时条件的方法，比如 wait 或 join 等方法的指定超时时间
- 终止（TERMINATED），不管是意外退出还是正常执行结束，线程已经完成使命，终止运行，也有人把这个状态叫作死亡。
线程同步以及线程调度相关的方法
- wait()：使一个线程处于等待（阻塞）状态，并且释放所持有的对象的锁；
- sleep()：使一个正在运行的线程处于睡眠状态，是一个静态方法，调用此方法要处理 InterruptedException 异常；
- yield()方法仅释放CPU执行权，锁仍然占用，线程会被放入就绪队列，会在短时间内再次执行
- notify()：唤醒一个处于等待状态的线程，当然在调用此方法的时候，并不能确切的唤醒 某一个等待状态的线程，而是由 JVM 确定唤醒哪个线程，而且与优先级无关；
- notityAll()：唤醒所有处于等待状态的线程，该方法并不是将对象的锁给所有线程，而是 让它们竞争，只有获得锁的线程才能进入就绪状态；。
线程优先级的理解
每一个线程都是有优先级的，一般来说，高优先级的线程在运行时会具有优先权，但这依赖于线程调度的实现，这个实现是和操作系统相关的(OS dependent)。我们可以定义线程的优先级，但是这并不能保证高优先级的线程会在低优先级的线程前执行。线程优先级是一个int变量(从1-10)，1代表最低优先级，10代表最高优先级。
java的线程优先级调度会委托给操作系统去处理，所以与具体的操作系统优先级有关，如非特别需要，一般无需设置线程优先级。
线程调度器(Thread Scheduler)和时间分片(Time Slicing )
线程调度器是一个操作系统服务，它负责为Runnable状态的线程分配CPU时间。一旦我们创建一个线程并启动它，它的执行便依赖于线程调度器的实现。
同上一个问题，线程调度并不受到Java虚拟机控制，所以由应用程序来控制它是更好的选择（也就是说不要让你的程序依赖于线程的优先级）。
时间分片是指将可用的CPU时间分配给可用的Runnable线程的过程。分配CPU时间可以基于线程优先级或者线程等待的时间。
创建线程
- 继承Thread类，重写run（）方法；
- 实现Runnable接口，实现run（）方法；
- 实现Callable接口，实现call（）方法。Future 监听返回，因为Runnable对象无法向调用者返回结果，我们可以用Callable类来返回结果。
- CompletableFuture，CompletableFuture 在Future的基础上增加了异步调用的功能。callback()函数Thread执行结束的时候会自动调用。
- CompletableFuture既支持阻塞，也支持非阻塞的callback()
runnable 和 callable 区别
相同点：
- 都是接口
- 都可以编写多线程程序
- 都采用Thread.start()启动线程
主要区别
- Runnable 接口 run 方法无返回值；Callable 接口 call 方法有返回值，是个泛型，和Future、FutureTask配合可以用来获取异步执行的结果
- Runnable 接口 run 方法只能抛出运行时异常，且无法捕获处理；Callable 接口 call 方法允许抛出异常，可以获取异常信息
注：Callalbe接口支持返回执行结果，需要调用FutureTask.get()得到
线程的 run()和 start()有什么区别？为什么我们调用 start() 方法时会执行 run() 方法，为什么我们不能直接调用 run() 方法？
每个线程都是通过某个特定Thread对象所对应的方法run()来完成其操作的，run()方法称为线程体。通过调用Thread类的start()方法来启动一个线程。也就是说start() 方法用于启动线程，run() 方法用于执行线程任务。run() 可以重复调用，而 start() 只能调用一次。
start()方法来启动一个线程，真正实现了多线程运行。调用start()方法无需等待run方法体代码执行完毕，可以直接继续执行其他的代码；此时线程是处于就绪状态，并没有运行。然后通过此Thread类调用方法run()来完成其运行状态， run()方法运行结束， 此线程终止。然后CPU再调度其它线程。
run()方法是在本线程里的，只是线程里的一个函数，而不是多线程的。如果直接调用run()，其实就相当于是调用了一个普通函数而已，直接调用run()方法必须等待run()方法执行完毕才能执行下面的代码，所以执行路径还是只有一条，根本就没有线程的特征，所以在多线程执行时要使用start()方法而不是run()方法。
什么是Callable、Future和FutureTask
Callable接口类似于Runnable，从名字就可以看出来了，但是Runnable不会返回结果，并且无法抛出返回结果的异常，而Callable功能更强大一些，被线程执行后，可以返回值，这个返回值可以被Future拿到，也就是说，Future可以拿到异步执行任务的返回值。
可以认为是带有回调的Runnable。
Future接口表示异步任务，是还没有完成的任务给出的未来结果。所以说Callable用于产生结果，Future用于获取结果。
Future 接口表示异步计算的任务，他提供了判断任务是否完成，中断任务，并可以通过get方法获取任务执行结果，该方法会阻塞直到任务返回结果。因为Future只是一个接口，所以是无法直接用来创建对象使用的，因此就有了下面的FutureTask。
FutureTask 类间接实现了 Future 接口，可以看出RunnableFuture继承了Runnable接口和Future接口，而FutureTask实现了RunnableFuture接口。所以它既可以作为Runnable被线程执行，又可以作为Future得到Callable的返回值。
FutureTask使用ExecutorService启动任务。
在Java并发程序中FutureTask表示一个可以取消的异步运算。它有启动和取消运算、查询运算是否完成和取回运算结果等方法。只有当运算完成的时候结果才能取回，如果运算尚未完成get方法将会阻塞。一个FutureTask对象可以对调用了Callable和Runnable的对象进行包装，由于FutureTask也是调用了Runnable接口所以它可以提交给Executor来执行。
停止线程
使用共享变量的方式
在这种方式中，之所以引入共享变量，是因为该变量可以被多个执行相同任务的线程用来作为是否中断的信号，通知中断线程的执行。
使用interrupt方法终止线程
如果一个线程由于等待某些事件的发生而被阻塞，又该怎样停止该线程呢？这种情况经常会发生，比如当一个线程由于需要等候键盘输入而被阻塞，或者调用Thread.join()方法，或者Thread.sleep()方法，在网络中调用ServerSocket.accept()方法，或者调用了DatagramSocket.receive()方法时，都有可能导致线程阻塞，使线程处于处于不可运行状态时，即使主程序中将该线程的共享变量设置为true，但该线程此时根本无法检查循环标志，当然也就无法立即中断。这里我们给出的建议是，不要使用stop()方法，而是使用Thread提供的interrupt()方法，因为该方法虽然不会中断一个正在运行的线程，但是它可以使一个被阻塞的线程抛出一个中断异常，从而使线程提前结束阻塞状态，退出堵塞代码。
你如何确保main()方法所在的线程是Java 程序最后结束的线程？
我们可以使用Thread类的join()方法来确保所有程序创建的线程在main()方法退出前结束。
为什么我们调用start()方法时会执行run()方法，为什么我们不能直接调用run()方法？
当你调用start()方法时你将创建新的线程，并且执行在run()方法里的代码。
但是如果你直接调用run()方法，它不会创建新的线程也不会执行调用线程的代码，只会把run方法当作普通方法去执行。
Java中你怎样唤醒一个阻塞的线程？
在Java发展史上曾经使用suspend()、resume()方法对于线程进行阻塞唤醒，但随之出现很多问题，比较典型的还是死锁问题。
解决方案可以使用以对象为目标的阻塞，即利用Object类的wait()和notify()方法实现线程阻塞。
首先，wait、notify方法是针对对象的，调用任意对象的wait()方法都将导致线程阻塞，阻塞的同时也将释放该对象的锁，相应地，调用任意对象的notify()方法则将随机解除该对象阻塞的线程，但它需要重新获取改对象的锁，直到获取成功才能往下执行；其次，wait、notify方法必须在synchronized块或方法中被调用，并且要保证同步块或方法的锁对象与调用wait、notify方法的对象是同一个，如此一来在调用wait之前当前线程就已经成功获取某对象的锁，执行wait阻塞后当前线程就将之前获取的对象锁释放。
notify 和 notifyAll 区别
先解释两个概念
等待池：假设一个线程A调用了某个对象的wait()方法，线程A就会释放该对象的锁后，进入到了该对象的等待池，等待池中的线程不会去竞争该对象的锁。
锁池：只有获取了对象的锁，线程才能执行对象的 synchronized 代码，对象的锁每次只有一个线程可以获得，其他线程只能在锁池中等待
区别：notify() 方法随机唤醒对象的等待池中的一个线程，进入锁池；notifyAll() 唤醒对象的等待池中的所有线程，进入锁池。
sleep 和 wait 区别
对于sleep()方法，我们首先要知道该方法是属于Thread类中的。而wait()方法，则是属于Object类中的。
sleep()方法导致了程序暂停执行指定的时间，让出cpu该其他线程，但是他的监控状态依然保持者，当指定的时间到了又会自动恢复运行状态。在调用sleep()方法的过程中，线程不会释放对象锁。
当调用wait()方法的时候，线程会放弃对象锁，进入等待此对象的等待锁定池，只有针对此对象调用notify()方法后本线程才进入对象锁定池准备，获取对象锁进入运行状态。
线程的 sleep()方法和 yield()方法有什么区别？
- sleep()方法给其他线程运行机会时不考虑线程的优先级，因此会给低优先级的线程以运行的机会；yield()方法只会给相同优先级或更高优先级的线程以运行的机会；
- 线程执行 sleep()方法后转入阻塞（blocked）状态，而执行 yield()方法后转入就绪（ready）状态；
- sleep()方法声明抛出 InterruptedException，而 yield()方法没有声明任何异常；
- sleep()方法比 yield()方法（跟操作系统 CPU 调度相关）具有更好的可移植性，通常不建议使用yield()方法来控制并发线程的执行。
为什么Thread类的sleep()和yield ()方法是静态的？
Thread类的sleep()和yield()方法将在当前正在执行的线程上运行。所以在其他处于等待状态的线程上调用这些方法是没有意义的。这就是为什么这些方法是静态的。它们可以在当前正在执行的线程中工作，并避免程序员错误的认为可以在其他非运行线程调用这些方法。
为什么wait, notify 和 notifyAll这些方法不在thread类里面？
一个很明显的原因是JAVA提供的锁是对象级的而不是线程级的，每个对象都有锁，通过线程获得。由于wait，notify和notifyAll都是锁级别的操作，所以把他们定义在Object类中因为锁属于对象。
为什么wait和notify方法要在同步块中调用？
Java API强制要求这样做，如果你不这么做，你的代码会抛出IllegalMonitorStateException异常。还有一个原因是为了避免wait和notify之间产生竞态条件。
Java中interrupted 和 isInterrupted方法的区别？
interrupt方法用于中断线程。调用该方法的线程的状态为将被置为”中断”状态。
注意：线程中断仅仅是置线程的中断状态位，不会停止线程。需要用户自己去监视线程的状态为并做处理。支持线程中断的方法（也就是线程中断后会抛出interruptedException的方法）就是在监视线程的中断状态，一旦线程的中断状态被置为“中断状态”，就会抛出中断异常。
interrupted查询当前线程的中断状态，并且清除原状态。如果一个线程被中断了，第一次调用interrupted则返回true，第二次和后面的就返回false了。
多线程同步和互斥有几种实现方法，都是什么？
线程同步是指线程之间所具有的一种制约关系，一个线程的执行依赖另一个线程的消息，当它没有得到另一个线程的消息时应等待，直到消息到达时才被唤醒。
线程互斥是指对于共享的进程系统资源，在各单个线程访问时的排它性。当有若干个线程都要使用某一共享资源时，任何时刻最多只允许一个线程去使用，其它要使用该资源的线程必须等待，直到占用资源者释放该资源。线程互斥可以看成是一种特殊的线程同步。
线程间的同步方法大体可分为两类：用户模式和内核模式。顾名思义，内核模式就是指利用系统内核对象的单一性来进行同步，使用时需要切换内核态与用户态，而用户模式就是不需要切换到内核态，只在用户态完成操作。
用户模式下的方法有：原子操作（例如一个单一的全局变量），临界区。内核模式下的方法有：事件，信号量，互斥量。
同步方法和同步块，哪个是更好的选择？
同步块是更好的选择，因为它不会锁住整个对象（当然你也可以让它锁住整个对象）。同步方法会锁住整个对象，哪怕这个类中有多个不相关联的同步块，这通常会导致他们停止执行并需要等待获得这个对象上的锁。
同步块更要符合开放调用的原则，只在需要锁住的代码块锁住相应的对象，这样从侧面来说也可以避免死锁。
怎么检测一个线程是否拥有锁？
在java.lang.Thread中有一个方法叫holdsLock()，它返回true如果当且仅当当前线程拥有某个具体对象的锁。
ThreadLocal是什么
首先，它是一个数据结构，有点像HashMap，可以保存"key : value"键值对，但是一个ThreadLocal只能保存一个，并且各个线程的数据互不干扰。
每个线程中都有一个ThreadLocalMap数据结构，当执行set方法时，其值是保存在当前线程的threadLocals变量中，当执行set方法中，是从当前线程的threadLocals变量获取。
在ThreadLoalMap中，也是初始化一个大小16的Entry数组，Entry对象用来保存每一个key-value键值对，只不过这里的key永远都是ThreadLocal对象，是不是很神奇，通过ThreadLocal对象的set方法，结果把ThreadLocal对象自己当做key，放进了ThreadLoalMap中。
这里需要注意的是，ThreadLoalMap的Entry是继承WeakReference，和HashMap很大的区别是，Entry中没有next字段，所以就不存在链表的情况了。
ThreadLocal造成内存泄漏的原因
当使用ThreadLocal保存一个value时，会在ThreadLocalMap中的数组插入一个Entry对象，按理说key-value都应该以强引用保存在Entry对象中，但在ThreadLocalMap的实现中，key被保存到了WeakReference对象中。因为为 ThreadLocal 的弱引用，而 value 是强引用。所以，如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。这样一来，ThreadLocalMap 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。
ThreadLocal内存泄漏解决方案
调用ThreadLocal的get()、set()可能会清除ThreadLocalMap中key为null的Entry对象，这样对应的value就没有GC Roots可达了，下次GC的时候就可以被回收，当然如果调用remove方法，肯定会删除对应的Entry对象。
如果使用ThreadLocal的set方法之后，没有显示的调用remove方法，就有可能发生内存泄露
同步有几种实现方法
同步方法
即有synchronized关键字修饰的方法。
由于java的每个对象都有一个内置锁，当用此关键字修饰方法时，内置锁会保护整个方法。在调用该方法前，需要获得内置锁，否则就处于阻塞状态。
同步代码块
即有synchronized关键字修饰的语句块。
被该关键字修饰的语句块会自动被加上内置锁，从而实现同步。
使用特殊域变量(volatile)实现线程同步
- volatile关键字为域变量的访问提供了一种免锁机制，
- 使用volatile修饰域相当于告诉虚拟机该域可能会被其他线程更新，
- 因此每次使用该域就要重新计算，而不是使用寄存器中的值
- volatile不会提供任何原子操作，它也不能用来修饰final类型的变量
使用重入锁实现线程同步
在JavaSE5.0中新增了一个java.util.concurrent包来支持同步。ReentrantLock类是可重入、互斥、实现了Lock接口的锁，它与使用synchronized方法和快具有相同的基本行为和语义，并且扩展了其能力。
乐观锁和悲观锁
乐观锁是假设每次操作都不会冲突，若是遇到冲突失败就重试直到成功；悲观锁是让其他线程都等待，等锁释放完了再竞争锁。
乐观锁实现方式：cas，volatile
悲观锁实现方式：synchronized，Lock
公平锁和非公平锁
根据线程获取锁的抢占机制，锁又可以分为公平锁和非公平锁。
公平锁是指多个线程按照申请锁的顺序来获取锁。
非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。
ReentrantLock 提供了公平锁和非公平锁的实现。
公平锁：new ReentrantLock(true)
非公平锁：new ReentrantLock(false)
如果构造函数不传任何参数的时候，默认提供的是非公平锁。
独占锁和共享锁
根据锁能否被多个线程持有，可以把锁分为独占锁和共享锁。
独占锁是指任何时候都只有一个线程能执行资源操作。
共享锁指定是可以同时被多个线程读取，但只能被一个线程修改。比如 Java 中的 ReentrantReadWriteLock 就是共享锁的实现方式，它允许一个线程进行写操作，允许多个线程读操作。
可重入锁
可重入锁指的是该线程获取了该锁之后，可以无限次的进入该锁锁住的代码。
public class Lock{
boolean isLocked = false;
Thread lockedBy = null;
int lockedCount = 0;
public synchronized void lock()
throws InterruptedException{
Thread thread = Thread.currentThread();
while(isLocked && lockedBy != thread){
wait();
}
isLocked = true;
lockedCount++;
lockedBy = thread;
}
public synchronized void unlock(){
if(Thread.currentThread() == this.lockedBy){
lockedCount--;
if(lockedCount == 0){
isLocked = false;
notify();
}
}
}
}ReentrantLock重入锁
是实现Lock接口的一个类，也是在实际编程中使用频率很高的一个锁，支持重入性，表示能够对共享资源重复加锁，即当前线程获取该锁再次获取时不会被阻塞。
ReentrantReadWriteLock 是 ReadWriteLock 接口的一个具体实现，实现了读写的分离，读锁是共享的，写锁是独占的，读和读之间不会互斥，读和写、写和读、写和写之间才会互斥，提升了读写的性能。
而读写锁有以下三个重要的特性：
- 公平选择性：支持非公平（默认）和公平的锁获取方式，吞吐量还是非公平优于公平。
- 可重入：读锁和写锁都支持线程可重入。
- 锁降级：遵循先获取写入锁，然后获取读取锁，最后释放写入锁。写锁能够降级成为读锁，但是，从读取锁升级到写入锁是不可能的。
重入性的实现原理
以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。
自旋锁
自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗 CPU。
CAS 与 ABA
CAS（Compare and Swap）比较并交换，是一种乐观锁的实现，是用非阻塞算法来代替锁定，其中 java.util.concurrent 包下的 AtomicInteger 就是借助 CAS 来实现的。
但 CAS 也不是没有任何副作用，比如著名的 ABA 问题就是 CAS 引起的。
AQS原理
AQS：AbstractQuenedSynchronizer抽象的队列式同步器。是除了java自带的synchronized关键字之外的锁机制，这个类在java.util.concurrent.locks包
AQS的核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置为锁定状态，如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。
CLH（Craig，Landin，and Hagersten）队列是一个虚拟的双向队列，虚拟的双向队列即不存在队列实例，仅存在节点之间的关联关系。
AQS是将每一条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node），来实现锁的分配。
用大白话来说，AQS就是基于CLH队列，用volatile修饰共享变量state，线程通过CAS去改变状态符，成功则获取锁成功，失败则进入等待队列，等待被唤醒。
注意：AQS是自旋锁：**在等待唤醒的时候，经常会使用自旋（while(!cas())）的方式，不停地尝试获取锁，直到被其他线程获取成功
实现了AQS的锁有：自旋锁、互斥锁、读锁写锁、条件产量、信号量、栅栏都是AQS的衍生物
AQS实现的具体方式如下：
如图示，AQS维护了一个volatile int state和一个FIFO线程等待队列，多线程争用资源被阻塞的时候就会进入这个队列。state就是共享资源，其访问方式有如下三种：
getState();setState();compareAndSetState();
AQS 定义了两种资源共享方式
- Exclusive：独占，只有一个线程能执行，如ReentrantLock
- Share：共享，多个线程可以同时执行，如Semaphore、CountDownLatch、ReadWriteLock，CyclicBarrier
不同的自定义的同步器争用共享资源的方式也不同。
AQS底层使用了模板方法模式
同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）：
使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放）
将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。
这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。
自定义同步器在实现的时候只需要实现共享资源state的获取和释放方式即可，至于具体线程等待队列的维护，AQS已经在顶层实现好了。自定义同步器实现的时候主要实现下面几种方法：
isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。
ReentrantLock为例，（可重入独占式锁）：state初始化为0，表示未锁定状态，A线程lock()时，会调用tryAcquire()独占锁并将state+1.之后其他线程再想tryAcquire的时候就会失败，直到A线程unlock（）到state=0为止，其他线程才有机会获取该锁。A释放锁之前，自己也是可以重复获取此锁（state累加），这就是可重入的概念。
注意：获取多少次锁就要释放多少次锁，保证state是能回到零态的。
以CountDownLatch为例，任务分N个子线程去执行，state就初始化 为N，N个线程并行执行，每个线程执行完之后countDown（）一次，state就会CAS减一。当N子线程全部执行完毕，state=0，会unpark()主调用线程，主调用线程就会从await()函数返回，继续之后的动作。
一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。
在acquire() acquireShared()两种方式下，线程在等待队列中都是忽略中断的，acquireInterruptibly()/acquireSharedInterruptibly()是支持响应中断的
AQS的应用
基于AQS实现的同步器有：ReentranLock、ReentrantReadWriteLock、CountDownLatch、Semaphore、FutureTask。AQS支持独占锁，比如ReentranLock。还支持共享锁，比如CountDownLatch、Semaphore。在AQS中维护了一个 volatile 修饰的状态信息 state，对于ReentranLock，state表示当前线程获取锁的可重入次数；对于CountDownLatch，state表示当前计数器的值；对于Semaphore，state表示当前可用信号的个数。
锁
JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销
锁主要存在四中状态
依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率
偏向锁
引入偏向锁的目的和引入轻量级锁的目的很像，他们都是为了没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。但是不同是：轻量级锁在无竞争的情况下使用 CAS 操作去代替使用互斥量。而偏向锁在无竞争的情况下会把整个同步都消除掉。
偏向锁的“偏”就是偏心的偏，它的意思是会偏向于第一个获得它的线程，如果在接下来的执行中，该锁没有被其他线程获取，那么持有偏向锁的线程就不需要进行同步！关于偏向锁的原理可以查看《深入理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。
但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。
轻量级锁
倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)。轻量级锁不是为了代替重量级锁，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗，因为使用轻量级锁时，不需要申请互斥量。另外，轻量级锁的加锁和解锁都用到了CAS操作。 关于轻量级锁的加锁和解锁的原理可以查看《深入理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。
轻量级锁能够提升程序同步性能的依据是“对于绝大部分锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥操作的开销。但如果存在锁竞争，除了互斥量开销外，还会额外发生CAS操作，因此在有锁竞争的情况下，轻量级锁比传统的重量级锁更慢！如果锁竞争激烈，那么轻量级将很快膨胀为重量级锁！
自旋锁和自适应自旋
轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。
互斥同步对性能最大的影响就是阻塞的实现，因为挂起线程/恢复线程的操作都需要转入内核态中完成（用户态转换到内核态会耗费时间）。
一般线程持有锁的时间都不是太长，所以仅仅为了这一点时间去挂起线程/恢复线程是得不偿失的。 所以，虚拟机的开发团队就这样去考虑：“我们能不能让后面来的请求获取锁的线程等待一会而不被挂起呢？看看持有锁的线程是否很快就会释放锁”。为了让一个线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就叫做自旋。
百度百科对自旋锁的解释：
何谓自旋锁？它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。
自旋锁在 JDK1.6 之前其实就已经引入了，不过是默认关闭的，需要通过--XX:+UseSpinning参数来开启。JDK1.6及1.6之后，就改为默认开启的了。需要注意的是：自旋等待不能完全替代阻塞，因为它还是要占用处理器时间。如果锁被占用的时间短，那么效果当然就很好了！反之，相反！自旋等待的时间必须要有限度。如果自旋超过了限定次数任然没有获得锁，就应该挂起线程。自旋次数的默认值是10次，用户可以修改--XX:PreBlockSpin来更改。
另外,在 JDK1.6 中引入了自适应的自旋锁。自适应的自旋锁带来的改进就是：自旋的时间不在固定了，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定，虚拟机变得越来越“聪明”了。
锁消除
锁消除理解起来很简单，它指的就是虚拟机即使编译器在运行时，如果检测到那些共享数据不可能存在竞争，那么就执行锁消除。锁消除可以节省毫无意义的请求锁的时间。
锁粗化
原则上，我们再编写代码的时候，总是推荐将同步快的作用范围限制得尽量小——只在共享数据的实际作用域才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待线程也能尽快拿到锁。
大部分情况下，上面的原则都是没有问题的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，那么会带来很多不必要的性能消耗。
锁是如何存储的
我们每个人在学习java中接触到的最多的一句话之一我想肯定是：一切皆对象。锁就是一个对象，那么这个对象里面的结构是怎么样的呢，锁对象里面都保存了哪些信息呢？
在Hotspot 虚拟机中，对象在内存中的存储布局，可以分为三个区域:对象头(Header)、实例数据(Instance Data)、对齐填充(Padding)。synchronized用的锁是存在Java对象头里的，Java对象头里面包含两部分信息：
第一部分官方称之为“Mark Word” ,用于存储自身的运行时数据，如：HashCode,GC分代年龄，锁标记、偏向锁线程ID等；第二部分是类型指针，即对象指向它的类元信息，虚拟机通过这个指针来确定这个对象是哪个类的实例(如果java对象是一个数组，那么对象头中还必须有一块用于记录数组长度的数据)
到这里我们就知道了，锁是记录在对象头中的“Mark Word”，那么“Mark Word”又是如何存储锁的信息的呢？
Java对象头的组成
锁存在于Java对象头里，对象头的组成部分：
Mark Word：存储对象的hashCode或锁信息等。
Class Metadata Address：存储到对象类型数据的指针。
Array length：数组的长度（如果当前对象是数组）
Java对象头又存在于Java堆中，堆内存分为三部分：对象头，实例数据和对齐填充。
MarkWord的组成
Java对象头的MardWord中记录了对象和锁的相关信息，无锁状态下，Java对象头里的Mark Word里默认存储对象的HashCode、分代年龄和锁标记位。在64位的JVM中，Mark Word为64 bit。
在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。锁升级的功能也主要靠MarkWord中锁标志位和是否偏向锁标志完成。：
锁升级的过程
锁升级的过程：无锁，偏向锁，轻量级锁，重量级锁
偏向锁的适用场景
偏向锁主要用于优化：同一线程多次申请同一个锁的竞争，在某些情况下，大部分时间都是同一个线程竞争锁资源的。
偏向锁的加锁
主要流程：当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。
- 如果测试成功，表示线程已经获得了锁。
- 如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：
-
- 如果没有设置，则使用CAS竞争锁。
- 如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。
偏向锁的撤销
一旦出现其他线程竞争锁资源时，偏向锁就会被撤销。偏向锁的撤销可能需要等待全局安全点【在这个时间点上没有正在执行的字节码】。
- 首先暂停持有该锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态。
- 如果持有偏向锁的线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒在暂停的线程。
偏向锁的关闭
偏向锁在Java 6和Java 7里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟：-XX:BiasedLockingStartupDelay=0。
如果锁通常处于竞争状态，可以通过- XX:-UseBiasedLocking=false，进入轻量级锁状态。
轻量级锁
如偏向锁存在，如有另一线程竞争锁，且对象头MarkWord中的线程ID与当前线程ID不同，则该线程将会尝试CAS操作获取锁，获取失败，代表锁存在竞争，偏向锁向轻量级锁升级。
轻量级锁的加锁
线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间【Displaced Mark Word】，并将对象头中的Mark Word复制到锁记录中。
然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。
- 替换成功，则当前线程获得锁。
- 替换失败，表示其他线程竞争锁，当前线程尝试使用自旋来获取锁。
轻量级锁的解锁
使用原子的CAS操作将【Displaced Mark Word】替换回对象头。
- 替换成功，表示没有竞争发生。
- 替换失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。
轻量级锁的适用场景
线程交替执行同步块，绝大部分的锁在整个同步周期内都不存在长时间的竞争。
锁的优缺点对比
| 锁 |
优点 |
缺点 |
适用场景 |
| 偏向锁 |
加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距。 |
如果线程间存在锁竞争， 会带来额外的锁撤销的消耗。 |
适用于只有一个线程访问同步块场景。 |
| 轻量级锁 |
竞争的线程不会阻塞，提高了程序的响应速度。 |
如果始终得不到锁竞争的线程使用自旋会消耗CPU。 |
追求响应时间。同步块执行速度非常快。 |
| 重量级锁 |
线程竞争不使用自旋，不会消耗CPU。 |
线程阻塞，响应时间缓慢。 |
追求吞吐量。同步块执行速度较长。 |
对于synchronized关键字的了解
synchronized关键字用于解决多个线程之间访问资源的同步性，synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。
值得注意的是，在Java早期，JDK1.6之前，synchronized属于重量级锁，效率低下。原因在于：
监视器锁【monitor】依赖于底层操作系统的Mutex Lock实现，Java的线程是映射到操作系统的原生线程之上的。如果要挂起或唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转化到内核态，需要消耗比较长的时间。
但是，JDK1.6之后，Java官方从JVM层面对synchronized关键字进行了较大的优化，效率不可同日而语。主要的优化有：自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
synchronized关键字的三种使用
修饰实例方法：作用于当前对象实例加锁，进入同步代码前要获得 当前对象实例的锁。
修饰静态方法: 也就是给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 当前 class 的锁。
注意：静态成员不属于任何一个实例对象，是类成员！因此，一个线程A调用一个实例对象的非静态synchronized方法，一个线程B调用这个实例对象的所属类的静态synchronized方法，是被允许的。
因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
修饰代码块 ：给括号内配置的对象加锁。synchronized(this|object) 表示进入同步代码库前要获得给定对象的锁。synchronized(类.class) 表示进入同步代码前要获得 当前 class 的锁。
synchronized关键字的底层原理
同步方法通过ACC_SYNCHRONIZED修饰。
代码块同步使用monitorenter和monitorexit两个指令实现。
虽然两者实现细节不同，但其实本质上都是JVM基于进入和退出Monitor对象来实现同步，JVM的要求如下：
monitorenter指令会在编译后插入到同步代码块的开始位置，而monitorexit则会插入到方法结束和异常处。
每个对象都有一个monitor与之关联，且当一个monitor被持有之后，他会处于锁定状态。
线程执行到monitorenter时，会尝试获取对象对应monitor的所有权。
在获取锁时，如果对象没被锁定，或者当前线程已经拥有了该对象的锁（可重进入，不会锁死自己），将锁计数器加一，执行monitorexit时，锁计数器减一，计数为零则锁释放。
获取对象锁失败，则当前线程陷入阻塞，直到对象锁被另外一个线程释放。
JDK1.6之后对synchronized关键字进行的优化
在多线程并发编程中synchronized 一直是元老级角色，很多人都会称呼它为重量级锁。但是随着Java SE 1.6 对synchronized 进行了各种优化之后，有些情况下它就并不那么重，Java SE 1.6 中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁。
在Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。至于锁的降级并没有一个标准，在达到一定的苛刻条件之后可以进行降级，但是一般情况我们可以简单的认为锁不可以降级。
Lock锁和synchronized锁的区别
共同点，都是可重入锁：自己可以再次获取自己的内部锁【避免一个线程获取锁之后，再次尝试获取锁时造成的死锁】。同一线程每次获取锁，计数器加一，释放锁，计数器减一，计数为0，代表完全释放该锁。
不同点：
- synchronized依赖于JVM实现，ReentrantLock依赖于API。
- 相比synchronized，ReentrantLock增加了一些高级功能。主要来说主要有三点：
等待可中断 : ReentrantLock提供了一种能够中断等待锁的线程的机制，通过 lock.lockInterruptibly() 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
可实现公平锁 : ReentrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。ReentrantLock默认情况是非公平的，可以通过 ReentrantLock类的ReentrantLock(boolean fair)构造方法来制定是否是公平的。
可实现选择性通知（锁可以绑定多个条件）: synchronized关键字与wait()和notify()/notifyAll()方法相结合可以实现等待/通知机制。ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition()方法。
| 特性 |
synchronized |
ReentrantLock |
相同 |
| 可重入 |
是 |
是 |
✅ |
| 响应中断 |
否 |
是 |
❌ |
| 超时等待 |
否 |
是 |
❌ |
| 公平锁 |
否 |
是 |
❌ |
| 非公平锁 |
是 |
是 |
✅ |
| 是否可尝试加锁 |
否 |
是 |
❌ |
| 是否是Java内置特性 |
是 |
否 |
❌ |
| 自动获取/释放锁 |
是 |
否 |
❌ |
| 对异常的处理 |
自动释放锁 |
需手动释放锁 |
❌ |
Lock 接口(Lock interface)是什么？对比 synchronized 它有什么优势？
Lock 接口比同步方法和同步块提供了更具扩展性的锁操作。Lock 接口缺少了（通过synchronized块或者方法所提供的）隐式获取释放锁的便捷性，但是却拥有了锁获取与释放的可操作性、可中断的获取锁以及超时获取锁等多种synchronized关键字所不具备的同步特性。
整体上来说 Lock 是 synchronized 的扩展版，Lock 提供了无条件的、可轮询的(tryLock 方法)、定时的(tryLock 带参方法)、可中断的(lockInterruptibly)、可多条件队列的(newCondition 方法)锁操作。另外 Lock 的实现类基本都支持非公平锁(默认)和公平锁，synchronized 只支持非公平锁，当然，在大部分情况下，非公平锁是高效的选择。
synchronized和java.util.concurrent.locks.Lock的异同
主要相同点：Lock能完成Synchronized所实现的所有功能。
主要不同点：Lock有比Synchronized更精确的线程予以和更好的性能。Synchronized会自动释放锁，但是Lock一定要求程序员手工释放，并且必须在finally从句中释放。
SynchronizedMap和ConcurrentHashMap有什么区别？
SynchronizedMap()和Hashtable一样，实现上在调用map所有方法时，都对整个map进行同步。而ConcurrentHashMap的实现却更加精细，它对map中的所有桶加了锁。所以，只要有一个线程访问map，其他线程就无法进入map，而如果一个线程在访问ConcurrentHashMap某个桶时，其他线程，仍然可以对map执行某些操作。
所以，ConcurrentHashMap在性能以及安全性方面，明显比Collections.synchronizedMap()更加有优势。同时，同步操作精确控制到桶，这样，即使在遍历map时，如果其他线程试图对map进行数据修改，也不会抛出ConcurrentModificationException。
volatile
volatile可以保证线程可见性且提供了一定的有序性，但是无法保证原子性。在JVM底层volatile是采用“内存屏障”来实现的。
1.volatile是java虚拟机提供的轻量级的同步机制
(1)保证可见性(2)不保证原子性(2禁止指令重排
2.volatile 写读的内存语义
volatile能使得一个非原子操作变成原子操作吗
一个典型的例子是在类中有一个 long 类型的成员变量。如果你知道该成员变量会被多个线程访问，如计数器、价格等，你最好是将其设置为 volatile。
因为 Java 中读取 long 类型变量不是原子的，需要分成两步，如果一个线程正在修改该 long 变量的值，另一个线程可能只能看到该值的一半（前 32 位）。但是对一个 volatile 型的 long 或 double 变量的读写是原子。
volatile修饰符有过什么实践
一种实践是用 volatile 修饰 long 和 double 变量，使其能按原子类型来读写。
double 和 long 都是64位宽，因此对这两种类型的读是分为两部分的，第一次读取第一个 32 位，然后再读剩下 的 32 位，这个过程不是原子的，但 Java 中 volatile 型的 long 或 double 变量的读写是原子的。
volatile 修饰符的另一个作用是提供内存屏障（memory barrier），例如在分布式框架中的应用。
简单的说，就是当你写一个 volatile 变量之前，Java 内存模型会插入一个写屏障（write barrier），读一个 volatile 变量之前，会插入一个读屏障（read barrier）。意思就是说，在你写一个 volatile 域时，能保证任何线程都能看到你写的值，同时，在写之前，也能保证任何数值的更新对所有线程是可见的，因为内存屏障会将其他所有写的值更新到缓存。
volatile类型变量提供什么保证
volatile 变量提供顺序和可见性保证，例如，JVM 或者 JIT为了获得更好的性能会对语句重排序，但是 volatile 类型变量即使在没有同步块的情况下赋值也不会与其他语句重排序。
volatile 提供 happens-before 的保证，确保一个线程的修改能对其他线程是可见的。
某些情况下，volatile 还能提供原子性，如读 64 位数据类型，像 long 和 double 都不是原子的，但 volatile 类型的 double 和 long 就是原子的。
volatile 变量和 atomic 变量有什么不同
Volatile变量可以确保先行关系，即写操作会发生在后续的读操作之前, 但它并不能保证原子性。例如用volatile修饰count变量那么 count++ 操作就不是原子性的。
而AtomicInteger类提供的atomic方法可以让这种操作具有原子性如getAndIncrement()方法会原子性的进行增量操作把当前值加一，其它数据类型和引用变量也可以进行相似操作。
volatile和synchronized的区别
（1）volatile保证变量的可见性，即只保证了对volatile变量读和写操作的原子性，并不能保证对i++这种复合操作的原子性。 而synchronized则是锁定当前临界资源，只有当前线程可以访问该资源，其他线程被阻塞住。保证了可见性和原子性。
（2）volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和代码块和类。
（3）volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。
双端检锁（DCL）机制是线程安全的吗？
DCL不一定是线程安全的，原因是有指令重排的存在，加入volatile可禁止指令重排。
原因在于在一个线程执行检测时，读取道德instance不为null，instance的引用对象可能没有完成初始化。
instance=new SingletonDemo();可以分为一下3个步骤：
(1) memory=allocate//分配内存空间
(2)instance(memory)//初始化对象
(3)instance=memory//设置instance指向刚分配的内存地址，此时instance!=null
步骤2和步骤3不存在数据依赖关系，而且无论重排前还是重排后程序的执行结果在单线程中没有改变，因此这种重排优化是允许的。
4. memory = allocate(); //分配对象内存空间
5. instance = memory; //设置instance指向刚分配的内存地址，此时instance != null,但是对象还没有初始化完成！
6. instance(memory); //初始化对象
但是指令重排只会保证穿行语义的执行的一致性（单线程），但并不会关心多线程间的语义一致性。所以当一条线程访问instance不为null时，由于instance实例未必已初始化完成，也就造成了线程安全问题。
public class VolatileDclDemo {
//private static VolatileDclDemo instance;
private static volatile VolatileDclDemo instance;
public VolatileDclDemo() {
System.out.println(Thread.currentThread().getName() + "\t VolatileDclDemo构造方法VolatileDclDemo()");
}
//DCL(Dooble Check Lock 双端检索机制)
public VolatileDclDemo getInstance(){
if (instance == null){
synchronized (VolatileDclDemo.class){
if (instance == null){
instance = new VolatileDclDemo();
}
}
}
return instance;
}
}CopyOnWriteArrayList可以用于什么应用场景？
CopyOnWriteArrayList的特性是针对读操作，不做处理，和普通的ArrayList性能一样。而在写操作时，会先拷贝一份，实现新旧版本的分离，然后在拷贝的版本上进行修改操作，修改完后，将其更新至就版本中。
那么他的使用场景就是：一个需要在多线程中操作，并且频繁遍历。其解决了由于长时间锁定整个数组导致的性能问题，解决方案即写时拷贝。
另外需要注意的是CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器
线程池概念
线程池： 简单理解，它就是一个管理线程的池子。
它帮我们管理线程，避免增加创建线程和销毁线程的资源损耗。因为线程其实也是一个对象，创建一个对象，需要经过类加载过程，销毁一个对象，需要走GC垃圾回收流程，都是需要资源开销的。
提高响应速度。 如果任务到达了，相对于从线程池拿线程，重新去创建一条线程执行，速度肯定慢很多。
重复利用。 线程用完，再放回池子，可以达到重复利用的效果，节省资源。
几个核心参数的作用：
corePoolSize： 线程池核心线程数最大值
maximumPoolSize： 线程池最大线程数大小
keepAliveTime： 线程池中非核心线程空闲的存活时间大小
unit： 线程空闲存活时间单位
workQueue： 存放任务的阻塞队列
threadFactory： 用于设置创建线程的工厂，可以给创建的线程设置有意义的名字，可方便排查问题。
handler： 线城池的饱和策略事件，主要有四种类型。
ThreadPoolExecutor 有哪些常用的方法？
submit()/execute()：执行线程池
shutdown()/shutdownNow()：终止线程池
isShutdown()：判断线程是否终止
getActiveCount()：正在运行的线程数
getCorePoolSize()：获取核心线程数
getMaximumPoolSize()：获取最大线程数
getQueue()：获取线程池中的任务队列
allowCoreThreadTimeOut(boolean)：设置空闲时是否回收核心线程这些方法可以用来终止线程池、线程池监控等。
四种拒绝策略
AbortPolicy(抛出一个异常，默认的)
DiscardPolicy(直接丢弃任务)
DiscardOldestPolicy（丢弃队列里最老的任务，将当前这个任务继续提交给线程池）
CallerRunsPolicy（交给线程池调用所在的线程进行处理)
有哪几种创建线程池的方式？
使用 Executors 工具类创建线程池
Executors提供了一系列工厂方法用于创先线程池，返回的线程池都实现了ExecutorService接口。
主要有newSingleThreadExecutor，newFixedThreadPool，newCachedThreadPool，newScheduledThreadPool
《阿里巴巴Java开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写程序的同学更加明确线程池的运行规则，规避资源耗尽的风险
Executors 各个方法的弊端：
newFixedThreadPool 和 newSingleThreadExecutor：主要问题是堆积的请求处理队列可能会耗费非常大的内存，甚至 OOM。
newCachedThreadPool 和 newScheduledThreadPool：主要问题是线程数最大数是 Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至 OOM。
ThreaPoolExecutor创建线程池方式只有一种，就是走它的构造函数，参数自己指定
submit(和 execute两个方法有什么区别？
submit() 和 execute() 都是用来执行线程池的，只不过使用 execute() 执行线程池不能有返回方法，而使用 submit() 可以使用 Future 接收线程池执行的返回值。
shutdownNow() 和 shutdown() 两个方法有什么区别？
shutdownNow() 和 shutdown() 都是用来终止线程池的，它们的区别是，使用 shutdown() 程序不会报错，也不会立即终止线程，它会等待线程池中的缓存任务执行完之后再退出，执行了 shutdown() 之后就不能给线程池添加新任务了；shutdownNow() 会试图立马停止任务，如果线程池中还有缓存任务正在执行，则会抛出 java.lang.InterruptedException: sleep interrupted 异常。
了解过线程池的工作原理吗？
当线程池中有任务需要执行时，线程池会判断如果线程数量没有超过核心数量就会新建线程池进行任务执行，如果线程池中的线程数量已经超过核心线程数，这时候任务就会被放入任务队列中排队等待执行；如果任务队列超过最大队列数，并且线程池没有达到最大线程数，就会新建线程来执行任务；如果超过了最大线程数，就会执行拒绝执行策略。
线程池中核心线程数量大小怎么设置？
「CPU密集型任务」：比如像加解密，压缩、计算等一系列需要大量耗费 CPU 资源的任务，大部分场景下都是纯 CPU 计算。尽量使用较小的线程池，一般为CPU核心数+1。因为CPU密集型任务使得CPU使用率很高，若开过多的线程数，会造成CPU过度切换。
「IO密集型任务」：比如像 MySQL 数据库、文件的读写、网络通信等任务，这类任务不会特别消耗 CPU 资源，但是 IO 操作比较耗时，会占用比较多时间。可以使用稍大的线程池，一般为2*CPU核心数。IO密集型任务CPU使用率并不高，因此可以让CPU在等待IO的时候有其他线程去处理别的任务，充分利用CPU时间。
另外：线程的平均工作时间所占比例越高，就需要越少的线程；线程的平均等待时间所占比例越高，就需要越多的线程；
以上只是理论值，实际项目中建议在本地或者测试环境进行多次调优，找到相对理想的值大小。
线程池为什么需要使用（阻塞）队列？
主要有三点：因为线程若是无限制的创建，可能会导致内存占用过多而产生OOM，并且会造成cpu过度切换。创建线程池的消耗较高。
线程池为什么要使用阻塞队列而不使用非阻塞队列？
阻塞队列可以保证任务队列中没有任务时阻塞获取任务的线程，使得线程进入wait状态，释放cpu资源。
当队列中有任务时才唤醒对应线程从队列中取出消息进行执行。
使得在线程不至于一直占用cpu资源。
（线程执行完任务后通过循环再次从任务队列中取出任务进行执行，代码片段如下
while (task != null || (task = getTask()) != null) {}）。
不用阻塞队列也是可以的，不过实现起来比较麻烦而已，有好用的为啥不用呢？
了解线程池状态吗？
通过获取线程池状态，可以判断线程池是否是运行状态、可否添加新的任务以及优雅地关闭线程池等。
- RUNNING：线程池的初始化状态，可以添加待执行的任务。
- SHUTDOWN：线程池处于待关闭状态，不接收新任务仅处理已经接收的任务。
- STOP：线程池立即关闭，不接收新的任务，放弃缓存队列中的任务并且中断正在处理的任务。TIDYING：线程池自主整理状态，调用 terminated() 方法进行线程池整理。
- TERMINATED：线程池终止状态。
知道线程池中线程复用原理吗？
线程池将线程和任务进行解耦，线程是线程，任务是任务，摆脱了之前通过 Thread 创建线程时的一个线程必须对应一个任务的限制。
在线程池中，同一个线程可以从阻塞队列中不断获取新任务来执行，其核心原理在于线程池对 Thread 进行了封装，并不是每次执行任务都会调用 Thread.start() 来创建新线程，而是让每个线程去执行一个“循环任务”，在这个“循环任务”中不停的检查是否有任务需要被执行，如果有则直接执行，也就是调用任务中的 run 方法，将 run 方法当成一个普通的方法执行，通过这种方式将只使用固定的线程就将所有任务的 run 方法串联起来。
线程池异常处理
在使用线程池处理任务的时候，任务代码可能抛出RuntimeException，抛出异常后，线程池可能捕获它，也可能创建一个新的线程来代替异常的线程，我们可能无法感知任务出现了异常，因此我们需要考虑线程池异常情况。
当提交新任务时，异常如何处理?
线程池都有哪几种工作队列？
LinkedBlockingQueue（可设置容量队列）基于链表结构的阻塞队列，按FIFO排序任务，容量可以选择进行设置，不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE，吞吐量通常要高于ArrayBlockingQuene；newFixedThreadPool线程池使用了这个队列
DelayQueue（延迟队列）是一个任务定时周期的延迟执行的队列。根据指定的执行时间从小到大排序，否则根据插入到队列的先后排序。newScheduledThreadPool线程池使用了这个队列。
PriorityBlockingQueue（优先级队列）是具有优先级的无界阻塞队列；
SynchronousQueue（同步队列）一个不存储元素的阻塞队列，每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQuene，newCachedThreadPool线程池使用了这个队列。
几种常用的线程池
newFixedThreadPool (固定数目线程的线程池)
newCachedThreadPool(可缓存线程的线程池)
newSingleThreadExecutor(单线程的线程池)
newScheduledThreadPool(定时及周期执行的线程池)
内存模型解决并发问题主要采用两种方式
- 限制处理器优化
- 使用内存屏障
关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成：
- lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
- unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
- read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
- load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
- use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
- assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
- store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
- write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。
如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。也就是read和load之间，store和write之间是可以插入其他指令的，如对主内存中的变量a、b进行访问时，可能的顺序是read a，read b，load b， load a。Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：
不允许read和load、store和write操作之一单独出现
不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。
不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
一个变量在同一时刻只允许一条线程对其进行lock操作，lock和unlock必须成对出现
如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。
为什么代码会重排序？
在执行程序时，为了提高性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件：
- 在单线程环境下不能改变程序运行的结果；
- 存在数据依赖关系的不允许重排序
需要注意的是：重排序不会影响单线程环境的执行结果，但是会破坏多线程的执行语义。
as-if-serial规则和happens-before规则的区别
as-if-serial语义保证单线程内程序的执行结果不被改变，happens-before语义保证正确同步的多线程程序的执行结果不被改变。
as-if-serial语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。happens-before语义给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按happens-before指定的顺序来执行的。
as-if-serial语义和happens-before这么做的目的
什么是并发容器的实现？
何为同步容器：可以简单地理解为通过synchronized来实现同步的容器，如果有多个线程调用同步容器的方法，它们将会串行执行。比如Vector，Hashtable，以及Collections.synchronizedSet，synchronizedList等方法返回的容器。
可以通过查看Vector，Hashtable等这些同步容器的实现代码，可以看到这些容器实现线程安全的方式就是将它们的状态封装起来，并在需要同步的方法上加上关键字synchronized。
并发容器使用了与同步容器完全不同的加锁策略来提供更高的并发性和伸缩性，例如在ConcurrentHashMap中采用了一种粒度更细的加锁机制，可以称为分段锁，在这种锁机制下，允许任意数量的读线程并发地访问map，并且执行读操作的线程和写操作的线程也可以并发的访问map，同时允许一定数量的写操作线程并发地修改map，所以它可以在并发环境下实现更高的吞吐量。
在Java中CycliBarriar和CountdownLatch有什么区别？
CyclicBarrier可以重复使用，而CountdownLatch不能重复使用。
Java的concurrent包里面的CountDownLatch其实可以把它看作一个计数器，只不过这个计数器的操作是原子操作，同时只能有一个线程去操作这个计数器，也就是同时只能有一个线程去减这个计数器里面的值。
你可以向CountDownLatch对象设置一个初始的数字作为计数值，任何调用这个对象上的await()方法都会阻塞，直到这个计数器的计数值被其他的线程减为0为止。
所以在当前计数到达零之前，await 方法会一直受阻塞。之后，会释放所有等待的线程，await的所有后续调用都将立即返回。这种现象只出现一次——计数无法被重置。如果需要重置计数，请考虑使用 CyclicBarrier。
CountDownLatch的一个非常典型的应用场景是：有一个任务想要往下执行，但必须要等到其他的任务执行完毕后才可以继续往下执行。假如我们这个想要继续往下执行的任务调用一个CountDownLatch对象的await()方法，其他的任务执行完自己的任务后调用同一个CountDownLatch对象上的countDown()方法，这个调用await()方法的任务将一直阻塞等待，直到这个CountDownLatch对象的计数值减到0为止。
CyclicBarrier一个同步辅助类，它允许一组线程互相等待，直到到达某个公共屏障点 (common barrier point)。在涉及一组固定大小的线程的程序中，这些线程必须不时地互相等待，此时 CyclicBarrier 很有用。因为该 barrier 在释放等待线程后可以重用，所以称它为循环 的 barrier。
什么是不可变对象，它对写并发应用有什么帮助？
不可变对象(Immutable Objects)即对象一旦被创建它的状态（对象的数据，也即对象属性值）就不能改变，反之即为可变对象(Mutable Objects)。
不可变对象的类即为不可变类(Immutable Class)。Java平台类库中包含许多不可变类，如String、基本类型的包装类、BigInteger和BigDecimal等。
不可变对象天生是线程安全的。它们的常量（域）是在构造函数中创建的。既然它们的状态无法修改，这些常量永远不会变。
不可变对象永远是线程安全的。
只有满足如下状态，一个对象才是不可变的；
它的状态不能在创建后再被修改；
所有域都是final类型；并且，
它被正确创建（创建期间没有发生this引用的逸出）。
StringBuffer、StringBuilder、String区别
线程安全
StringBuffer：线程安全，StringBuilder：线程不安全。因为 StringBuffer 的所有公开方法都是 synchronized 修饰的，而 StringBuilder 并没有 synchronized 修饰。
StringBuffer 代码片段：
@Override
public synchronized StringBuffer append(String str) {
toStringCache = null;
super.append(str);
return this;
}缓冲区
StringBuffer 代码片段：
private transient char[] toStringCache;
@Override
public synchronized String toString() {
if (toStringCache == null) {
toStringCache = Arrays.copyOfRange(value, 0, count);
}
return new String(toStringCache, true);
}StringBuilder 代码片段：
@Override
public String toString() {
// Create a copy, don't share the array
return new String(value, 0, count);
}可以看出，StringBuffer 每次获取 toString 都会直接使用缓存区的 toStringCache 值来构造一个字符串。
而 StringBuilder 则每次都需要复制一次字符数组，再构造一个字符串。
所以，缓存冲这也是对 StringBuffer 的一个优化吧，不过 StringBuffer 的这个toString 方法仍然是同步的。
性能
StringBuffer 是线程安全的，它的所有公开方法都是同步的，StringBuilder 是没有对方法加锁同步的，所以毫无疑问，StringBuilder 的性能要远大于 StringBuffer。
StringBuilder > StringBuffer > String
String最慢的原因：String为字符串常量，而StringBuilder和StringBuffer均为字符串变量，即String对象一旦创建之后该对象是不可更改的，但后两者的对象是变量，是可以更改的。
限流方案
一文搞定，手撸Springboot + aop + Lua分布式限流的最佳实践_vincent-CSDN博客_springboot限流设置
1、计数器
Java内部也可以通过原子类计数器AtomicInteger、Semaphore信号量来做简单的限流。
// 限流的个数
private int maxCount = 10;
// 指定的时间内
private long interval = 60;
// 原子类计数器
private AtomicInteger atomicInteger = new AtomicInteger(0);
// 起始时间
private long startTime = System.currentTimeMillis();
public boolean limit(int maxCount, int interval) {
atomicInteger.addAndGet(1);
if (atomicInteger.get() == 1) {
startTime = System.currentTimeMillis();
atomicInteger.addAndGet(1);
return true;
}
// 超过了间隔时间，直接重新开始计数
if (System.currentTimeMillis() - startTime > interval * 1000) {
startTime = System.currentTimeMillis();
atomicInteger.set(1);
return true;
}
// 还在间隔时间内,check有没有超过限流的个数
if (atomicInteger.get() > maxCount) {
return false;
}
return true;
}
2、漏桶算法
漏桶算法思路很简单，我们把水比作是请求，漏桶比作是系统处理能力极限，水先进入到漏桶里，漏桶里的水按一定速率流出，当流出的速率小于流入的速率时，由于漏桶容量有限，后续进入的水直接溢出（拒绝请求），以此实现限流。
3、令牌桶算法
令牌桶算法的原理也比较简单，我们可以理解成医院的挂号看病，只有拿到号以后才可以进行诊病。
系统会维护一个令牌（token）桶，以一个恒定的速度往桶里放入令牌（token），这时如果有请求进来想要被处理，则需要先从桶里获取一个令牌（token），当桶里没有令牌（token）可取时，则该请求将被拒绝服务。令牌桶算法通过控制桶的容量、发放令牌的速率，来达到对请求的限制。
秒杀系统
一个秒杀系统的设计思考_vincent-CSDN博客
分布式锁
三种实现分布式锁的方式_vincent-CSDN博客_分布式锁