JAVA并发编程面试题

1、什么是进程和线程 ？
答：进程是程序运行资源分配的最小单位
进程是操作系统进行资源分配的最小单位,其中资源包括:CPU、内存空间、 磁盘 IO 等,同一进程中的多条线程共享该进程中的全部系统资源,而进程和进程 之间是相互独立的。进程是具有一定独立功能的程序关于某个数据集合上的一次 运行活动,进程是系统进行资源分配和调度的一个独立单位。
进程是程序在计算机上的一次执行活动。当你运行一个程序,你就启动了一 个进程。显然,程序是死的、静态的,进程是活的、动态的。进程可以分为系统进 程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程,它们就 是处于运行状态下的操作系统本身,用户进程就是所有由你启动的进程。

线程是 CPU 调度的最小单位,必须依赖于进程而存在
线程是进程的一个实体,是 CPU 调度和分派的基本单位,它是比进程更小的、 能独立运行的基本单位。线程自己基本上不拥有系统资源,只拥有一点在运行中 必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其 他的线程共享进程所拥有的全部资源。

线程无处不在
任何一个程序都必须要创建线程,特别是 Java 不管任何程序都必须启动一个 main 函数的主线程;JavaWeb 开发里面的定时任务、定时器、JSP 和 Servlet、异 步消息处理机制,远程访问接口RM等,任何一个监听事件,onclick的触发事件等都 离不开线程和并发的知识。

2、线程的启动与中止
启动
启动线程的方式有：
1、XextendsThread;，然后 X.start
2、Ximplements Runnable；然后交给 Thread 运行
参见代码：cn.enjoyedu.ch1.base.NewThread
Thread和Runnable的区别 Thread 才是 Java 里对线程的唯一抽象，Runnable 只是对任务（业务逻辑） 的抽象。Thread 可以接受任意一个 Runnable 的实例并执行。
中 止
线程自然终止 要么是 run 执行完成了，要么是抛出了一个未处理的异常导致线程提前结束。stop暂停、恢复和停止操作对应在线程 Thread 的 API 就是 suspend()、resume() 和 stop()。但是这些 API 是过期的，也就是不建议使用的。不建议使用的原因主 要有：以 suspend()方法为例，在调用后，线程不会释放已经占有的资源（比如 锁），而是占有着资源进入睡眠状态，这样容易引发死锁问题。同样，stop()方 法在终结一个线程时不会保证线程的资源正常释放，通常是没有给予线程完成资 源释放工作的机会，因此会导致程序可能工作在不确定状态下。正因为 suspend()、 resume()和 stop()方法带来的副作用，这些方法才被标注为不建议使用的过期方法。
中断
安全的中止则是其他线程通过调用某个线程A的interrupt()方法对其进行中 断操作, 中断好比其他线程对该线程打了个招呼，“A，你要中断了”，不代表 线程 A 会立即停止自己的工作，同样的 A 线程完全可以不理会这种中断请求。 线程通过检查自身的中断标志位是否被置为 true 来进行响应，
线程通过方法 isInterrupted()来进行判断是否被中断，也可以调用静态方法 Thread.interrupted()来进行判断当前线程是否被中断，不过 Thread.interrupted() 会同时将中断标识位改写为 false。
如果一个线程处于了阻塞状态（如线程调用了 thread.sleep、thread.join、 thread.wait 等），则在线程在检查中断标示时如果发现中断标示为 true，则会在这些阻塞方法调用处抛出 InterruptedException 异常，并且在抛出异常后会立即 将线程的中断标示位清除，即重新设置为 false。
不建议自定义一个取消标志位来中止线程的运行。因为 run 方法里有阻塞调 用时会无法很快检测到取消标志，线程必须从阻塞调用返回后，才会检查这个取 消标志。这种情况下，使用中断会更好，因为，
一、一般的阻塞方法，如 sleep 等本身就支持中断的检查，
二、检查中断位的状态和检查取消标志位没什么区别，用中断位的状态还可 以避免声明取消标志位，减少资源的消耗。
注意：处于死锁状态的线程无法被中断

3、深入理解run()和start()
Thread类是Java里对线程概念的抽象，可以这样理解：我们通过newThread() 其实只是 new 出一个 Thread 的实例，还没有操作系统中真正的线程挂起钩来。 只有执行了 start()方法后，才实现了真正意义上的启动线程。
start()方法让一个线程进入就绪队列等待分配 cpu，分到 cpu 后才调用实现 的 run()方法，start()方法不能重复调用，如果重复调用会抛出异常。
而 run 方法是业务逻辑实现的地方，本质上和任意一个类的任意一个成员方 法并没有任何区别，可以重复执行，也可以被单独调用。
其他的线程相关方法
yield()方法：使当前线程让出 CPU 占有权，但让出的时间是不可设定的。也 不会释放锁资源。注意：并不是每个线程都需要这个锁的，而且执行 yield()的线 程不一定就会持有锁，我们完全可以在释放锁后再调用 yield 方法。
所有执行 yield()的线程有可能在进入到就绪状态后会被操作系统再次选中 马上又被执行。
而 notify()和notifyAll()的作用，则是唤醒当前对象上的等待线程；notify()是唤醒单个线程，而notifyAll()是唤醒所有的线程。
Object类中关于等待/唤醒的API详细信息如下：
　　notify() – 唤醒在此对象监视器上等待的单个线程，使其进入“就绪状态”。　　
　　notifyAll() – 唤醒在此对象监视器上等待的所有线程，使其进入“就绪状态”。
　　wait() – 让当前线程处于“等待(阻塞)状态”，“直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法”，当前线程被唤醒(进入“就绪状态”)。
　　wait(long timeout) – 让当前线程处于“等待(阻塞)状态”，“直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者超过指定的时间量”，当前线程被唤醒(进入“就绪状态”)。
　　wait(long timeout, int nanos) – 让当前线程处于“等待(阻塞)状态”，“直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者其他某个线程中断当前线程，或者已超过某个实际时间量”，当前线程被唤醒(进入“就绪状态”)。
wait()的作用是让“当前线程”等待（会释放锁），而“当前线程”是指正在cpu上运行的线程！
在调用 wait（）、notify()系列方法之前，线程必须要获得该对象的对象级 别锁，即只能在同步方法或同步块中调用 wait（）方法、notify()系列方法

4、调用 yield() 、sleep()、wait()、notify()等方法对锁有何影响？
答：yield() 、sleep()被调用后，都不会释放当前线程所持有的锁。 调用 wait()方法后，会释放当前线程持有的锁，而且当前被唤醒后，会重新 去竞争锁，锁竞争到后才会执行 wait 方法后面的代码。 调用 notify()系列方法后，对锁无影响，线程只有在 syn 同步代码执行完后才 会自然而然的释放锁，所以 notify()系列方法一般都是 syn 同步代码的最后一行。

5、现在有 T1、T2、T3 三个线程，你怎样保证 T2 在 T1 执行完后执行，T3 在 T2 执行完后执行？
答：这个多线程问题比较简单，可以用 join 方法实现。

6、在 Java 中 Lock 接口比 synchronized 块的优势是什么？你需要实现一个高效的缓存，它允 许多个用户读，但只允许一个用户写，以此来保持它的完整性，你会怎样去实现它？
答：lock 接口在多线程和并发编程中最大的优势是它们为读和写分别提供了锁，它能满足你写 像 ConcurrentHashMap 这样的高性能数据结构和有条件的阻塞。Java 线程面试的问题越来 越会根据面试者的回答来提问。我强烈建议在你去参加多线程的面试之前认真读一下 Locks，因为当前其大量用于构建电子交易终统的客户端缓存和交易连接空间。

7、用 Java 实现阻塞队列。
答：这是一个相对艰难的多线程面试问题，它能达到很多的目的。第一，它可以检测侯选者是 否能实际的用 Java 线程写程序；第二，可以检测侯选者对并发场景的理解，并且你可以根 据这个问很多问题。如果他用 wait()和 notify()方法来实现阻塞队列，你可以要求他用最新 的 Java 5 中的并发类来再写一次。

8、Synchronized 用过吗，其原理是什么。?
答:这是一道 Java 面试中几乎百分百会问到的问题，因为没有任何写过并发程序的开发者会没听说或者没接触过 Synchronized。
Synchronized 是由 JVM 实现的一种实现互斥同步的一种方式，如果你查看被 Synchronized 修饰过的程序块编译后的字节码，会发现，被 Synchronized 修饰过的程序块，在编译前后被编译器生成了monitorenter 和 monitorexit 两个字节码指令。
这两个指令是什么意思呢？
在虚拟机执行到 monitorenter 指令时，首先要尝试获取对象的锁：
如果这个对象没有锁定，或者当前线程已经拥有了这个对象的锁，把锁的计数器 +1；当执行 monitorexit 指令时将锁计数器 -1；当计数器为 0 时，锁就被释放了。
如果获取对象失败了，那当前线程就要阻塞等待，直到对象锁被另外一
个线程释放为止。
Java 中 Synchronize 通过在对象头设置标记，达到了获取锁和释放
锁的目的。

9、获取对象的锁，这个“锁”到底是什么？如何确定对象的锁？
答：“锁”的本质其实是 monitorenter 和 monitorexit 字节码指令的一个 Reference 类型的参数，即要锁定和解锁的对象。我们知道，使用 Synchronized 可以修饰不同的对象，因此，对应的对象锁可以这么确
定。

1. 如果 Synchronized 明确指定了锁对象，比如 Synchronized（变量名）、Synchronized(this) 等，说明加解锁对象为该对象。
2. 如果没有明确指定：
   若 Synchronized 修饰的方法为非静态方法，表示此方法对应的对象为锁对象；
   若 Synchronized 修饰的方法为静态方法，则表示此方法对应的类对象为锁对象。
   注意，当一个对象被锁住时，对象里面所有用 Synchronized 修饰的方法都将产生堵塞，而对象里非 Synchronized 修饰的方法可正常被调用，不受锁影响。

10、什么是可重入性，为什么说 Synchronized 是可重入锁？
答：可重入性是锁的一个基本要求，是为了解决自己锁死自己的情况。 一个类中的同步方法调用另一个同步方法，假如 Synchronized 不支持重入，进入 method2 方法时当前线程获得锁，method2 方法里面执行 method1 时当前线程又要去尝试获取锁，这时如果不支持重入，它就要等释放，把自己阻塞，导致自己锁死自己。
对 Synchronized 来说，可重入性是显而易见的，刚才提到，在执行 monitorenter 指令时，如果这个对象没有锁定，或者当前线程已经拥有了这个对象的锁（而不是已拥有了锁则不能继续获取），就把锁的计数器 +1，其实本质上就通过这种方式实现了可重入性。

11、JVM 对 Java 的原生锁做了哪些优化？
在 Java 6 之前，Monitor 的实现完全依赖底层操作系统的互斥锁来实现，也就是我们刚才在问题二中所阐述的获取/释放锁的逻辑。 由于 Java 层面的线程与操作系统的原生线程有映射关系，如果要将一个线程进行阻塞或唤起都需要操作系统的协助，这就需要从用户态切换到内核态来执行，这种切换代价十分昂贵，很耗处理器时间，现代 JDK 中做了大量的优化。
一种优化是使用自旋锁，即在把线程进行阻塞操作之前先让线程自旋等待一段时间，可能在等待期间其他线程已经解锁，这时就无需再让线程执行阻塞操作，避免了用户态到内核态的切换。
现代 JDK 中还提供了三种不同的 Monitor 实现，也就是三种不同的锁：
 偏向锁（Biased Locking）
 轻量级锁
 重量级锁
这三种锁使得 JDK 得以优化 Synchronized 的运行，当 JVM 检测到不同的竞争状况时，会自动切换到适合的锁实现，这就是锁的升级、降级。
 当没有竞争出现时，默认会使用偏向锁。
JVM 会利用 CAS 操作，在对象头上的 Mark Word 部分设置线程 ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁，因为在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，
使用偏斜锁可以降低无竞争开销。
 如果有另一线程试图锁定某个被偏斜过的对象，JVM 就撤销偏斜锁，切换到轻量级锁实现。
 轻量级锁依赖 CAS 操作 Mark Word 来试图获取锁，如果重试成功，就使用普通的轻量级锁；否则，进一步升级为重量级锁。

12、为什么说 Synchronized 是非公平锁？
答：非公平主要表现在获取锁的行为上，并非是按照申请锁的时间前后给等待线程分配锁的，每当锁被释放后，任何一个线程都有机会竞争到锁，这样做的目的是为了提高执行性能，缺点是可能会产生线程饥饿现象。

13、什么是锁消除和锁粗化？
锁消除：指虚拟机即时编译器在运行时，对一些代码上要求同步，但被检测到不可能存在共享数据竞争的锁进行消除。主要根据逃逸分析。 程序员怎么会在明知道不存在数据竞争的情况下使用同步呢？很多不是程序员自己加入的。
锁粗化：原则上，同步块的作用范围要尽量小。但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作在循环体内，频繁地进行互斥同步操作也会导致不必要的性能损耗。 锁粗化就是增大锁的作用域。

14、为什么说 Synchronized 是一个悲观锁？乐观锁的实现原理又是什么？什么是 CAS，它有什么特性？
答：Synchronized 显然是一个悲观锁，因为它的并发策略是悲观的： 不管是否会产生竞争，任何的数据操作都必须要加锁、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等操作。
随着硬件指令集的发展，我们可以使用基于冲突检测的乐观并发策略。先进行操作，如果没有其他线程征用数据，那操作就成功了； 如果共享数据有征用，产生了冲突，那就再进行其他的补偿措施。这种
乐观的并发策略的许多实现不需要线程挂起，所以被称为非阻塞同步。
乐观锁的核心算法是 CAS（Compareand Swap，比较并交换），它涉及到三个操作数：内存值、预期值、新值。当且仅当预期值和内存值相等时才将内存值修改为新值。 这样处理的逻辑是，首先检查某块内存的值是否跟之前我读取时的一样，如不一样则表示期间此内存值已经被别的线程更改过，舍弃本次操作，否则说明期间没有其他线程对此内存值操作，可以把新值设置给此
块内存。
CAS 具有原子性，它的原子性由 CPU 硬件指令实现保证，即使用 JNI 调用 Native 方法调用由 C++ 编写的硬件级别指令，JDK 中提供了 Unsafe 类执行这些操作。

15、乐观锁一定就是好的吗？
乐观锁避免了悲观锁独占对象的现象，同时也提高了并发性能，但它也有缺点：

1. 乐观锁只能保证一个共享变量的原子操作。如果多一个或几个变量，乐观锁将变得力不从心，但互斥锁能轻易解决，不管对象数量多少及对象颗粒度大小。
2. 长时间自旋可能导致开销大。假如 CAS 长时间不成功而一直自旋，会给 CPU 带来很大的开销。
3. ABA 问题。CAS 的核心思想是通过比对内存值与预期值是否一样而判断内存值是否被改过，但这个判断逻辑不严谨，假如内存值原来是 A，后来被一条线程改为 B，最后又被改成了 A，则 CAS 认为此内存值并没有发生改变，但实际上是有被其他线程改过的，这种情况对依赖过程值的情景的运算结果影响很大。解决的思路是引入版本号，每次变量更新都把版本号加一。

16、跟 Synchronized 相比，可重入锁 ReentrantLock 其实现原理有什么不同？
答：其实，锁的实现原理基本是为了达到一个目的： 让所有的线程都能看到某种标记。
Synchronized 通过在对象头中设置标记实现了这一目的，是一种 JVM 原生的锁实现方式，而 ReentrantLock 以及所有的基于 Lock 接口的实现类，都是通过用一个 volitile 修饰的 int 型变量，并保证每个线程都能拥有对该 int 的可见性和原子修改，其本质是基于所谓的 AQS 框架。

17、AQS 框架是怎么回事？
AQS（AbstractQueuedSynchronizer 类）是一个用来构建锁和同步器的框架，各种 Lock 包中的锁（常用的有 ReentrantLock、ReadWriteLock），以及其他如 Semaphore、CountDownLatch，甚至是早期的 FutureTask 等，都是基于 AQS 来构建。

1. AQS 在内部定义了一个 volatile int state 变量，表示同步状态：当线程调用 lock 方法时 ，如果 state=0，说明没有任何线程占有共享资源的锁，可以获得锁并将 state=1；如果 state=1，则说明有线程目前正在使用共享变量，其他线程必须加入同步队列进行等待。
2. AQS 通过 Node 内部类构成的一个双向链表结构的同步队列，来完成线程获取锁的排队工作，当有线程获取锁失败后，就被添加到队列末尾。 o Node 类是对要访问同步代码的线程的封装，包含了线程本身及其状态叫 waitStatus（有五种不同 取值，分别表示是否被阻塞，是否等待唤醒，是否已经被取消等），每个 Node 结点关联其 prev 结点和 next 结点，方便线程释放锁后快速唤醒下一个在等待的线程，是一个 FIFO 的过程。 o Node 类有两个常量，SHARED 和 EXCLUSIVE，分别代表共享模式和独占模式。所谓共享模式是一个锁允许多条线程同时操作（信号量 Semaphore 就是基于 AQS 的共享模式实现的），独占模式是同一个时间段只能有一个线程对共享资源进行操作，多余的请求线程需要排队等待（如 ReentranLock）。
3. AQS 通过内部类 ConditionObject 构建等待队列（可有多个），当 Condition 调用 wait() 方法后，线程将会加入等待队列中，而当 Condition 调用 signal() 方法后，线程将从等待队列转移动同步队列中进行锁竞争。
4. AQS 和 Condition 各自维护了不同的队列，在使用 Lock 和 Condition 的时候，其实就是两个队列的互相移动。

18、ReentrantLock 是如何实现可重入性的？
答：ReentrantLock 内部自定义了同步器 Sync（Sync 既实现了 AQS，又实现了 AOS，而 AOS 提供了一种互斥锁持有的方式），其实就是加锁的时候通过 CAS 算法，将线程对象放到一个双向链表中，每次获取锁的时候，看下当前维护的那个线程 ID 和当前请求的线程 ID 是否一样，一样就可重入了。

19、除了 ReetrantLock，你还接触过 JUC 中的哪些并发工具？
通常所说的并发包（JUC）也就是 java.util.concurrent 及其子包，集中了 Java 并发的各种基础工具类，具体主要包括几个方面：
 提供了 CountDownLatch、CyclicBarrier、Semaphore 等，比 Synchronized 更加高级，可以实现更加丰富多线程操作的同步结构。
 提供了 ConcurrentHashMap、有序的 ConcunrrentSkipListMap，或者通过类似快照机制实现线程安全的动态数组 CopyOnWriteArrayList 等，各种线程安全的容器。
 提供了 ArrayBlockingQueue、SynchorousQueue 或针对特定场景的 PriorityBlockingQueue 等，各种并发队列实现。
 强大的 Executor 框架，可以创建各种不同类型的线程池，调度任务运行等。

20、请谈谈 ReadWriteLock 和 StampedLock？
答：虽然 ReentrantLock 和 Synchronized 简单实用，但是行为上有一定局限性，要么不占，要么独占。实际应用场景中，有时候不需要大量竞争的写操作，而是以并发读取为主，为了进一步优化并发操作的粒度，Java 提供了读写锁。
读写锁基于的原理是多个读操作不需要互斥，如果读锁试图锁定时，写锁是被某个线程持有，读锁将无法获得，而只好等待对方操作结束，这样就可以自动保证不会读取到有争议的数据。
ReadWriteLock 代表了一对锁，下面是一个基于读写锁实现的数据结构，当数据量较大，并发读多、并发写少的时候，能够比纯同步版本凸显出优势：
读写锁看起来比 Synchronized 的粒度似乎细一些，但在实际应用中，其表现也并不尽如人意，主要还是因为相对比较大的开销。 所以，JDK 在后期引入了 StampedLock，在提供类似读写锁的同时，还支持优化读模式。优化读基于假设，大多数情况下读操作并不会和写操作冲突，其逻辑是先试着修改，然后通过 validate 方法确认是否进入了写模式，如果没有进入，就成功避免了开销；如果进入，则尝试获
取读锁。

21、如何让 Java 的线程彼此同步？你了解过哪些同步器？请分别介绍下。
答：JUC 中的同步器三个主要的成员：CountDownLatch、CyclicBarrier 和 Semaphore，通过它们可以方便地实现很多线程之间协作的功能。
CountDownLatch 叫倒计数，允许一个或多个线程等待某些操作完成。看几个场景：
 跑步比赛，裁判需要等到所有的运动员（“其他线程”）都跑到终点（达到目标），才能去算排名和颁奖。
 模拟并发，我需要启动 100 个线程去同时访问某一个地址，我希望它们能同时并发，而不是一个一个的去执行。
用法：CountDownLatch 构造方法指明计数数量，被等待线程调用 countDown 将计数器减 1，等待线程使用 await 进行线程等待
CyclicBarrier 叫循环栅栏，它实现让一组线程等待至某个状态之后再全部同时执行，而且当所有等待线程被释放后，CyclicBarrier 可以被重复使用。CyclicBarrier 的典型应用场景是用来等待并发线程结束。
CyclicBarrier 的主要方法是 await()，await() 每被调用一次，计数便会减少 1，并阻塞住当前线程。当计数减至 0 时，阻塞解除，所有在此 CyclicBarrier 上面阻塞的线程开始运行。 在这之后，如果再次调用 await()，计数就又会变成 N-1，新一轮重新开始，这便是 Cyclic 的含义所在。CyclicBarrier.await() 带有返回值，用来表示当前线程是第几个到达这个 Barrier 的线程。
Semaphore，Java 版本的信号量实现，用于控制同时访问的线程个数，来达到限制通用资源访问的目的，其原理是通过 acquire() 获取一个许可，如果没有就等待，而 release() 释放一个许可。
如果 Semaphore 的数值被初始化为 1，那么一个线程就可以通过 acquire 进入互斥状态，本质上和互斥锁是非常相似的。但是区别也非常明显，比如互斥锁是有持有者的，而对于 Semaphore 这种计数器结
构，虽然有类似功能，但其实不存在真正意义的持有者，除非我们进行扩展包装。