• 充分利用多核CPU计算能力：多核可以并发编程CPU 充分发挥计算能力，提高性能
• 便于业务拆分，提高系统并发能力和性能：在特殊业务场景下，先天性适合并发编程。现在的系统动不动就要求百万级甚至千万级的并发量，而多线程并发编程正是开发高并发系统的基础，利用好多线程机制可以大大提高系统整体的并发能力以及性能。面对复杂的业务模型，并行程序比串行程序更适合业务需求，并发程序更适合业务拆分 。

并发编程的目的是提高程序执行效率和运行速度，但并发编程并不总是提高程序运行速度，并发编程可能会遇到许多问题，如

并发编程三要素(线程安全问题体现在):

原子性：原子，即不可分割的颗粒。原子性是指一个或多个操作或多个操作 所有执行成功或全部执行失败。

可见性：一个线程修改共享变量，另一个线程可以立即看到。 （synchronized,volatile）

有序性：程序执行的顺序按代码的顺序执行。(处理器可能会执行指令 重排序）

线程安全问题的原因：

• 线程切换带来的原子性问题
• 缓存引起的可见性问题
• 编译优化带来的有序问题

解决办法：

• JDK Atomic原子类的开头，synchronized、LOCK，能解决原子性问题
• synchronized、volatile、LOCK，可以解决可见性问题
• Happens-Before 规则可以解决有序的问题

• 并发：多个任务在同一个 CPU 核上，按细分时间片轮流(交替)执行，从逻辑上讲 同时执行这些任务。
• 并行:多个处理器或多核处理器在单位时间内同时处理多个任务是真正意义上的 同时进行。
• 串行：有n个任务，由一个线程按顺序执行。由于任务、方法都在一个线程执行 因此，线程不安全，临界区也不存在问题。

做一个形象比喻:

并发 = 两队和一台咖啡机。
并行 = 两排和两台咖啡机。
串行 = 队列和咖啡机。

多线程：多线程是指程序中包含多个执行流，即多个执行流可以以同时运行多个执行流 执行不同程执行不同的任务。

多线程的优点： 可以提高 CPU 的利用率。在多线程程序中，一个线程必须等待的时候，CPU 可 运行其他线程而不是等待，这大大提高了程序的效率。也就是说，允许单独使用 创建多个并行执行的程序来完成各自的任务。

多线程的缺点：

• 线程也是程序，所以线程需要占用内存，线程占用的内存越多；
• 多线程需要协调和管理，因此需要 CPU 时间跟踪线程；
• 线程之间对共享资源的访问将相互影响，必须解决竞争共享资源的问题 题。

**进程 **

在内存中运行的应用程序。每个过程都有自己独立的内存空间，一个进入 例如，程可以有多个线程Windows一个操作系统xx.exe就是一个进 程。

线程

执行过程中的任务(控制单元)负责当前过程中程序的执行。一个过程到 很少有一个线程，一个过程可以运行多个线程，多个线程可以共享数据。

**过程与线程的区别 **

线程具有许多传统过程的特点，因此也被称为轻过程(Light—Weight Process)或过程元；传统的过程被称为重型过程(Heavy—Weight Process)， 它相当于只有一个线程的任务。在引入线程的操作系统中，通常有一个过程 至少包含一个线程。

**根本区别：**该过程是操作系统资源分配的基本单位，线程是处理器任务调度和执行 基本单位

**资源开销：**每个过程都有独立的代码和数据空间(上下文)，程序之间的切割 交换成本高；线程可以看作是一个轻量级的过程，同类线程共享代码和数据空 每个线程都有自己独立的运行栈和程序计数器（PC），开启线程之间的切换 销小。

**包含关系：**若一个过程中有多个线程，则执行过程不是一条线，而是多条线 (线程)共同完成；线程是过程的一部分，因此线程也称为轻权过程或轻权过程 量级进程。

**内存分配：**同一流程的线程共享流程的地址空间和资源，流程之间的地址空 间和资源相互独立

**影响关系：**一个过程崩溃后，在保护模式下不会影响其他过程，但一个 线程崩溃的整个过程都死了。因此，多过程比多线程更强大。

**执行过程：**每个独立过程包括程序运行的入口、顺序执行序列和程序出口。 线程不能独立执行，应用程序必须提供多个线程执行控制 制度可以并发执行

在多线程编程中，一般线程的数量大于 CPU 核心数，一个 CPU 核心在任 为了有效地执行这些线程，意时刻只能用一个线程，CPU 采取的 策略是将时间片分配到每个线程并旋转。当一个线程的时间片耗尽时 它将重新处于就绪状态，供其他线程使用，属于上下文切换。

综上所述，当前任务已经完成 CPU 切换到另一个任务前，时间片将首先保存 您自己的状态，以便下次切换到此任务时，您可以再次加载此任务的状态。任务
从保存到再加载的过程是上下文切换。

上下文切换通常是计算密集型的。换句话说，它需要相当多的处理器时间 在每秒几十次或几百次的切换中，每次切换都需要纳秒量级。因此，上下文切换 对于系统来说，这意味着消耗大量的系统 CPU 事实上，时间可能是操作系统中时间消耗最大的操作。

Linux 与其他操作系统相比(包括其他类别) Unix 系统)有很多优点，其中之一 上下文切换和模式切换的时间消耗很少。

保护线程和用户线程

• 用户 (User) 线程：在前台运行，执行程序主线程、连接网等具体任务 络的子线程等都是用户线程
• 守护 (Daemon) 线程：在后台运行，服务于其他前台线程。也可以说是守护 线程是 JVM 中非守护线程 仆人。一旦所有用户的线程都结束护线程 会随 JVM 一起完成工作

main 函数所在的线程是用户线程，main 函数同时启动 JVM 内部 还启动了许多保护线程，如垃圾回收线程。 最明显的区别之一是用户线程结束，JVM 无论此时是否有守护线，退出 行程运行。而且保护线程不会影响 JVM 的退出。

注意事项：

1. setDaemon(true)必须在start()方法前执行，否则会抛出 IllegalThreadStateException 异常
2. 守护线程中产生的新线程也是守护线程
3. 并非所有任务都可以分配给守护线程，如读写操作或计算 逻辑
4. 守护 (Daemon) 不能依靠线程 finally 确保块的内容关闭或清晰 资源管理的逻辑。因为我们上面也说过，一旦所有用户线程都结束运行，保持 护线程会随 JVM 一起完成工作，所以守护 (Daemon) 线程中的 finally 语 句块可能无法执行。

windows用任务管理器看上面，linux下可以用 top 看看这个工具。

1. 找出cpu消耗大量的过程pid， 终端执行top命令，然后按下shift p 查 找出cpu利用厉害的pid号
2. 根据上述第一步获得的信息pid号，top -H -p pid 。然后按下shift p，查 找出cpu利用率强的线程号，如top -H -p 1328
3. 将获得的线程号转换为16进制，去百度转换
4. 使用jstack打印输出过程信息，jstack pid号 > /tmp/t.dat，比 如jstack 31365 > /tmp/t.dat
5. 编辑/tmp/t.dat找到线程号对应的信息

百度百科:死锁是指在执行过程中竞争资金的两个或两个以上的过程(线程) 如果没有外力，它们将无法推动源或相互通信造成的阻塞现象 进去。此时，该系统处于死锁状态，或该系统产生死锁，这些总是相互等待 程(线程)称为死锁过程(线程)。

多个线程同时被阻塞，其中一个或全部等待释放资源。 程序被无限期阻塞，因此程序不可能正确终止。

如下图所示，线程 A 持有资源 2，线程 B 持有资源 1，他们同时都想申请对方 的资源，所以这两个线程就会互相等待而进入死锁状态。

线程死锁 下面通过一个例子来说明线程死锁，代码模拟了上图的死锁的情况 ：

1 public class DeadLockDemo { 
2  private static Object resource1 = new Object();//资源 1 
3  private static Object resource2 = new Object();//资源 2
4 
5  public static void main(String[] args) {
6  new Thread(() ‐> { 
7  synchronized (resource1) { 
8  System.out.println(Thread.currentThread() + "get resource1"); 
9  try { 
10  Thread.sleep(1000); 
11  } catch (InterruptedException e) { 
12  e.printStackTrace(); 
13  } 
14  System.out.println(Thread.currentThread() + "waiting get resource2"); 
15  synchronized (resource2) { 
16  System.out.println(Thread.currentThread() + "get resource2"); 
17  } 
18  } 
19  }, "线程 1").start();
20 
21  new Thread(() ‐> { 
22  synchronized (resource2) { 
23  System.out.println(Thread.currentThread() + "get resource2"); 
24  try { 
25  Thread.sleep(1000); 
26  } catch (InterruptedException e) { 
27  e.printStackTrace(); 
28  } 
29  System.out.println(Thread.currentThread() + "waiting get resource1"); 
30  synchronized (resource1) { 
31  System.out.println(Thread.currentThread() + "get resource1"); 
32  } 
33  } 
34  }, "线程 2").start(); 
35  } 
36 } 

输出结果

1 Thread[线程 1,5,main]get resource1 
2 Thread[线程 2,5,main]get resource2 
3 Thread[线程 1,5,main]waiting get resource2 
4 Thread[线程 2,5,main]waiting get resource1 

线程 A 通过 synchronized (resource1) 获得 resource1 的监视器锁，然后通 过Thread.sleep(1000)；让线程 A 休眠 1s 为的是让线程 B 得到CPU执行权，然 后获取到 resource2 的监视器锁。线程 A 和线程 B 休眠结束了都开始企图请求获取对方的资源，然后这两个线程就会陷入互相等待的状态，这也就产生了死 锁。上面的例子符合产生死锁的四个必要条件。

1. 互斥条件：线程(进程)对于所分配到的资源具有排它性，即一个资源只 能被一个线程(进程)占用，直到被该线程(进程)释放
2. 请求与保持条件：一个线程(进程)因请求被占用资源而发生阻塞时，对 已获得的资源保持不放。
3. 不剥夺条件：线程(进程)已获得的资源在末使用完之前不能被其他线程 强行剥夺，只有自己使用完毕后才释放资源。
4. 循环等待条件：当发生死锁时，所等待的线程(进程)必定会形成一个环 路（类似于死循环），造成永久阻塞

我们只要破坏产生死锁的四个条件中的其中一个就可以了。

破坏互斥条件

这个条件我们没有办法破坏，因为我们用锁本来就是想让他们互斥的（临界资源 需要互斥访问）。

破坏请求与保持条件

一次性申请所有的资源。

**破坏不剥夺条件 **

占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占 有的资源。

**破坏循环等待条件 **

靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环 等待条件。

我们对线程 2 的代码修改成下面这样就不会产生死锁了。

1 new Thread(() ‐> { 
2  synchronized (resource1) { 
3  System.out.println(Thread.currentThread() + "get resource1"); 
4  try { 
5  Thread.sleep(1000); 
6  } catch (InterruptedException e) { 
7  e.printStackTrace();
8  } 
9  System.out.println(Thread.currentThread() + "waiting get resource2"); 
10  synchronized (resource2) { 
11  System.out.println(Thread.currentThread() + "get resource2"); 
12  } 
13  } 
14 }, "线程 2").start(); 

输出结果

1 Thread[线程 1,5,main]get resource1 
2 Thread[线程 1,5,main]waiting get resource2 
3 Thread[线程 1,5,main]get resource2 
4 Thread[线程 2,5,main]get resource1 
5 Thread[线程 2,5,main]waiting get resource2 
6 Thread[线程 2,5,main]get resource2 

我们分析一下上面的代码为什么避免了死锁的发生?

线程 1 首先获得到 resource1 的监视器锁，这时候线程 2 就获取不到了。然后 线程 1 再去获取 resource2 的监视器锁，可以获取到。然后线程 1 释放了对 resource1、resource2 的监视器锁的占用，线程 2 获取到就可以执行了。这样 就破坏了破坏循环等待条件，因此避免了死锁。

创建线程有四种方式：

• 继承 Thread 类；
• 实现 Runnable 接口；
• 实现 Callable 接口；
• 使用 Executors 工具类创建线程池继承 Thread 类

步骤

1. 定义一个Thread类的子类，重写run方法，将相关逻辑实现，run()方法

就是线程要执行的业务逻辑方法

步骤

1. 定义Runnable接口实现类MyRunnable，并重写run()方法

2. 创建MyRunnable实例myRunnable，以myRunnable作为target创建Thead对象，该Thread对象才是真正的线程对象

3. 调用线程对象的start()方法

1 public class MyRunnable implements Runnable {
2
3	@Override
4	public void run() {
5	System.out.println(Thread.currentThread().getName() + " run()方法执行中...");
6	}
7
8 }
1 public class RunnableTest {
2
3	public static void main(String[] args) {
4	MyRunnable myRunnable = new MyRunnable();
5	Thread thread = new Thread(myRunnable);
6	thread.start();
7	System.out.println(Thread.currentThread().getName() + " main()方法执行完成");
8	}
9
10 }

执行结果

1	main main()方法执行完成
2	Thread‐0 run()方法执行中...

步骤

1. 创建实现Callable接口的类myCallable

2. 以myCallable为参数创建FutureTask对象

3. 将FutureTask作为参数创建Thread对象

4. 调用线程对象的start()方法

1 public class MyCallable implements Callable {
2
3	@Override
4	public Integer call() {
5	System.out.println(Thread.currentThread().getName() + " call()方法执行中...");
6	return 1;
7	}
8
9 }

1 public class CallableTest {
2
3	public static void main(String[] args) {
4	FutureTask futureTask = new FutureTask(new MyCallable());
5	Thread thread = new Thread(futureTask);
6	thread.start();
7
8	try {
9	Thread.sleep(1000);
10	System.out.println("返回结果 " + futureTask.get());
11	} catch (InterruptedException e) {
12	e.printStackTrace();
13	} catch (ExecutionException e) {
14	e.printStackTrace();
15	}
16	System.out.println(Thread.currentThread().getName() + " main()方法执行完成");
17	}
18
19 }

执行结果

1	Thread‐0 call()方法执行中...
2	返回结果 1
3	main main()方法执行完成

Executors提供了一系列工厂方法用于创先线程池，返回的线程池都实现了ExecutorService接口。主要有newFixedThreadPool，newCachedThreadPool，newSingleThreadExecutor，newScheduledThreadPool，后续详细介绍这四种线程池

1 public class MyRunnable implements Runnable {
2
3	@Override
4	public void run() {
5	System.out.println(Thread.currentThread().getName() + " run()方法执行中...");
6	}
7
8 }

1 public class SingleThreadExecutorTest {
2 
3  public static void main(String[] args) { 
4  ExecutorService executorService = Executors.newSingleThreadExecutor(); 
5  MyRunnable runnableTest = new MyRunnable(); 
6	for (int i = 0; i < 5; i++) {
7	executorService.execute(runnableTest);
8	}
9
10	System.out.println("线程任务开始执行");
11	executorService.shutdown();
12	}
13
14 }

执行结果

1	线程任务开始执行
2	pool‐1‐thread‐1 is running...
3	pool‐1‐thread‐1 is running...
4	pool‐1‐thread‐1 is running...
5	pool‐1‐thread‐1 is running...
6	pool‐1‐thread‐1 is running...

每个线程都是通过某个特定Thread对象所对应的方法run()来完成其操作的， run()方法称为线程体。通过调用Thread类的start()方法来启动一个线程。 start() 方法用于启动线程，run() 方法用于执行线程的运行时代码。run() 可以重复调用，而 start() 只能调用一次。 start()方法来启动一个线程，真正实现了多线程运行。调用start()方法无需等待 run方法体代码执行完毕，可以直接继续执行其他的代码； 此时线程是处于就绪状态，并没有运行。 然后通过此Thread类调用方法run()来完成其运行状态， run()方法运行结束， 此线程终止。然后CPU再调度其它线程。

run()方法是在本线程里的，只是线程里的一个函数，而不是多线程的。 如果直接调用run()，其实就相当于是调用了一个普通函数而已，直接待用run()方法必须等待run()方法执行完毕才能执行下面的代码，所以执行路径还是只有一条，根本就没有线程的特征，所以在多线程执行时要使用start()方法而不是run()方法

这是另一个非常经典的 java 多线程面试问题，而且在面试中会经常被问到。很简单，但是很多人都会答不上来！

new 一个 Thread，线程进入了新建状态。调用 start() 方法，会启动一个线程并使线程进入了就绪状态，当分配到时间片后就可以开始运行了。 start() 会执行线程的相应准备工作，然后自动执行 run() 方法的内容，这是真正的多线程工作。

而直接执行 run() 方法，会把 run 方法当成一个 main 线程下的普通方法去执行，并不会在某个线程中执行它，所以这并不是多线程工作。

总结： 调用 start 方法方可启动线程并使线程进入就绪状态，而 run 方法只是 thread 的一个普通方法调用，还是在主线程里执行。

Callable 接口类似于 Runnable，从名字就可以看出来了，但是 Runnable 不会返回结果，并且无法抛出返回结果的异常，而 Callable 功能更强大一些，被线程执行后，可以返回值，这个返回值可以被 Future 拿到，也就是说，Future 可以拿到异步执行任务的返回值。

Future 接口表示异步任务，是一个可能还没有完成的异步任务的结果。所以说

Callable用于产生结果，Future 用于获取结果。

FutureTask 表示一个异步运算的任务。FutureTask 里面可以传入一个

Callable 的具体实现类，可以对这个异步运算的任务的结果进行等待获取、判

断是否已经完成、取消任务等操作。只有当运算完成的时候结果才能取回，如果运算尚未完成 get 方法将会阻塞。一个 FutureTask 对象可以对调用了

Callable 和 Runnable 的对象进行包装，由于 FutureTask 也是Runnable 接口的实现类，所以 FutureTask 也可以放入线程池中。

1. 新建(new)：新创建了一个线程对象。

2. 可运行(runnable)：线程对象创建后，当调用线程对象的 start()方法，该线程处于就绪状态，等待被线程调度选中，获取cpu的使用权。

3. 运行(running)：可运行状态(runnable)的线程获得了cpu时间片

（timeslice），执行程序代码。注：就绪状态是进入到运行状态的唯一入口，也就是说，线程要想进入运行状态执行，首先必须处于就绪状态中；

4. 阻塞(block)：处于运行状态中的线程由于某种原因，暂时放弃对 CPU 的使用权，停止执行，此时进入阻塞状态，直到其进入到就绪状态，才 有机会再次被 CPU 调用以进入到运行状态。

阻塞的情况分三种：

(一). 等待阻塞：运行状态中的线程执行 wait()方法，JVM会把该线程放入等待队列(waitting queue)中，使本线程进入到等待阻塞状态；

(二). 同步阻塞：线程在获取 synchronized 同步锁失败(因为锁被其它线程所占用)，，则JVM会把该线程放入锁池(lock pool)中，线程会进入同步阻塞状态；

(三). 其他阻塞: 通过调用线程的 sleep()或 join()或发出了 I/O 请求时，线程会

进入到阻塞状态。当 sleep()状态超时、join()等待线程终止或者超时、或者 I/O 处理完毕时，线程重新转入就绪状态。

5. 死亡(dead)：线程run()、main()方法执行结束，或者因异常退出了 run()方法，则该线程结束生命周期。死亡的线程不可再次复生。

计算机通常只有一个 CPU，在任意时刻只能执行一条机器指令，每个线程只有获得CPU 的使用权才能执行指令。所谓多线程的并发运行，其实是指从宏观上看，各个线程轮流获得 CPU 的使用权，分别执行各自的任务。在运行池中，会有多个处于就绪状态的线程在等待 CPU，JAVA 虚拟机的一项任务就是负责线程的调度，线程调度是指按照特定机制为多个线程分配 CPU 的使用权。

有两种调度模型：分时调度模型和抢占式调度模型。

分时调度模型是指让所有的线程轮流获得 cpu 的使用权，并且平均分配每个线程占用的 CPU 的时间片这个也比较好理解。

ava虚拟机采用抢占式调度模型，是指优先让可运行池中优先级高的线程占用

CPU，如果可运行池中的线程优先级相同，那么就随机选择一个线程，使其占用

CPU。处于运行状态的线程会一直运行，直至它不得不放弃 CPU。

线程调度器选择优先级 高的线程运行，但是，如果发生以下情况，就会终止线程的运行：

（1） 线程体中调用了 yield 方法让出了对 cpu 的占用权利

（2） 线程体中调用了 sleep 方法使线程进入睡眠状态

（3） 线程由于 IO 操作受到阻塞

（4） 另外一个更高优先级线程出现

（5） 在支持时间片的系统中，该线程的时间片用完

线程调度器是一个操作系统服务，它负责为 Runnable 状态的线程分配 CPU 时间。一旦我们创建一个线程并启动它，它的执行便依赖于线程调度器的实现。时间分片是指将可用的 CPU 时间分配给可用的 Runnable 线程的过程。分配

CPU 时间可以基于线程优先级或者线程等待的时间。

线程调度并不受到 Java 虚拟机控制，所以由应用程序来控制它是更好的选择

（也就是说不要让你的程序依赖于线程的优先级）。

请说出与线程同步以及线程调度相关的方法。

（1） wait()：使一个线程处于等待（阻塞）状态，并且释放所持有的对象的锁；

（2） sleep()：使一个正在运行的线程处于睡眠状态，是一个静态方法，调用此方法要处理 InterruptedException 异常；

（3） notify()：唤醒一个处于等待状态的线程，当然在调用此方法的时候，并不能确切的唤醒某一个等待状态的线程，而是由 JVM 确定唤醒哪个线程，而且与优先级无关；

（4） notityAll()：唤醒所有处于等待状态的线程，该方法并不是将对象的锁给

所有线程，而是让它们竞争，只有获得锁的线程才能进入就绪状态；

两者都可以暂停线程的执行

• 类的不同：sleep() 是 Thread线程类的静态方法，wait() 是 Object类的方法。
• 是否释放锁：sleep() 不释放锁；wait() 释放锁。
• 用途不同：Wait 通常被用于线程间交互/通信，sleep 通常被用于暂停执行。
• 用法不同：wait() 方法被调用后，线程不会自动苏醒，需要别的线程调用同一个对象上的 notify() 或者 notifyAll() 方法。sleep() 方法执行完成后，线程会自动苏醒。或者可以使用wait(long timeout)超时后线程会自动苏醒。

你是如何调用 wait() 方法的？使用 if 块还是循环？为什么？处于等待状态的线程可能会收到错误警报和伪唤醒，如果不在循环中检查等待条件，程序就会在没有满足结束条件的情况下退出。

wait() 方法应该在循环调用，因为当线程获取到 CPU 开始执行的时候，其他条件可能还没有满足，所以在处理前，循环检测条件是否满足会更好。下面是一段标准的使用 wait 和 notify 方法的代码：

1	synchronized (monitor) {
2	// 判断条件谓词是否得到满足
3	while(!locked) {
4	// 等待唤醒
5	monitor.wait();
6	}
7	// 处理其他的业务逻辑
8	}

Java中，任何对象都可以作为锁，并且 wait()，notify()等方法用于等待对象的锁或者唤醒线程，在 Java 的线程中并没有可供任何对象使用的锁，所以任意对象调用方法一定定义在Object类中。

wait(), notify()和 notifyAll()这些方法在同步代码块中调用

有的人会说，既然是线程放弃对象锁，那也可以把wait()定义在Thread类里面啊，新定义的线程继承于Thread类，也不需要重新定义wait()方法的实现。然而，这样做有一个非常大的问题，一个线程完全可以持有很多锁，你一个线程放弃锁的时候，到底要放弃哪个锁？当然了，这种设计并不是不能实现，只是管理起来更加复杂。

综上所述，wait()、notify()和notifyAll()方法要定义在Object类中。

当一个线程需要调用对象的 wait()方法的时候，这个线程必须拥有该对象的锁，

接着它就会释放这个对象锁并进入等待状态直到其他线程调用这个对象上的

notify()方法。同样的，当一个线程需要调用对象的 notify()方法时，它会释放

这个对象的锁，以便其他在等待的线程就可以得到这个对象锁。由于所有的这些方法都需要线程持有对象的锁，这样就只能通过同步来实现，所以他们只能在同步方法或者同步块中被调用。

使当前线程从执行状态（运行状态）变为可执行态（就绪状态）。

当前线程到了就绪状态，那么接下来哪个线程会从就绪状态变成执行状态呢？可能是当前线程，也可能是其他线程，看系统的分配了。

Thread 类的 sleep()和 yield()方法将在当前正在执行的线程上运行。所以在其

他处于等待状态的线程上调用这些方法是没有意义的。这就是为什么这些方法是静态的。它们可以在当前正在执行的线程中工作，并避免程序员错误的认为可以在其他非运行线程调用这些方法。

（1） sleep()方法给其他线程运行机会时不考虑线程的优先级，因此会给低优先级的线程以运行的机会；yield()方法只会给相同优先级或更高优先级的线程以运行的机会；

（2） 线程执行 sleep()方法后转入阻塞（blocked）状态，而执行 yield()方法后转入就绪（ready）状态；

（3） sleep()方法声明抛出 InterruptedException，而 yield()方法没有声明任何异常；

（4） sleep()方法比 yield()方法（跟操作系统 CPU 调度相关）具有更好的可移植性，通常不建议使用yield()方法来控制并发线程的执行。

在java中有以下3种方法可以终止正在运行的线程：

\1. 使用退出标志，使线程正常退出，也就是当run方法完成后线程终止。

\2. 使用stop方法强行终止，但是不推荐这个方法，因为stop和suspend及 resume一样都是过期作废的方法。

\3. 使用interrupt方法中断线程。

interrupt：用于中断线程。调用该方法的线程的状态为将被置为”中断”状态。注意：线程中断仅仅是置线程的中断状态位，不会停止线程。需要用户自己去监

视线程的状态为并做处理。支持线程中断的方法（也就是线程中断后会抛出

interruptedException 的方法）就是在监视线程的中断状态，一旦线程的中断状态被置为“中断状态”，就会抛出中断异常。

interrupted：是静态方法，查看当前中断信号是true还是false并且清除中断信号。如果一个线程被中断了，第一次调用 interrupted 则返回 true，第二次和后面的就返回 false 了。

isInterrupted：查看当前中断信号是true还是false 什么是阻塞式方法？

阻塞式方法是指程序会一直等待该方法完成期间不做其他事情，ServerSocket 的accept()方法就是一直等待客户端连接。这里的阻塞是指调用结果返回之前，当前线程会被挂起，直到得到结果之后才会返回。此外，还有异步和非阻塞式方法在任务完成前就返回.

首先 ，wait()、notify() 方法是针对对象的，调用任意对象的 wait()方法都将导致线程阻塞，阻塞的同时也将释放该对象的锁，相应地，调用任意对象的

notify()方法则将随机解除该对象阻塞的线程，但它需要重新获取该对象的锁，直到获取成功才能往下执行；

其次，wait、notify 方法必须在 synchronized 块或方法中被调用，并且要保证同步块或方法的锁对象与调用 wait、notify 方法的对象是同一个，如此一来在调用 wait 之前当前线程就已经成功获取某对象的锁，执行 wait 阻塞后当前线程就将之前获取的对象锁释放。

如果线程调用了对象的 wait()方法，那么线程便会处于该对象的等待池中，等待池中的线程不会去竞争该对象的锁。

notifyAll() 会唤醒所有的线程，notify() 只会唤醒一个线程。

notifyAll() 调用后，会将全部线程由等待池移到锁池，然后参与锁的竞争，竞争

成功则继续执行，如果不成功则留在锁池等待锁被释放后再次参与竞争。而 notify()只会唤醒一个线程，具体唤醒哪一个线程由虚拟机控制。如何在两个线程间共享数据？在两个线程间共享变量即可实现共享。

一般来说，共享变量要求变量本身是线程安全的，然后在线程内使用的时候，如果有对共享变量的复合操作，那么也得保证复合操作的线程安全性。

可以通过中断 和 共享变量的方式实现线程间的通讯和协作比如说 经典的生产者-消费者模型：当队列满时，生产者需要等待队列有空间才能继续往里面放入商品，而在等待的期间内，生产者必须释放对临界资源（即队列）的占用权。因为生产者如果不释放对临界资源的占用权，那么消费者就无法消费队列中的商品，就不会让队列有空间，那么生产者就会一直无限等待下去。因此，一般情况下，当队列满时，会让生产者交出对临界资源的占用权，并进入挂起状态。然后等待消费者消费了商品，然后消费者通知生产者队列有空间了。同样地，当队列空时，消费者也必须等待，等待生产者通知它队列中有商品了。这种互相通信的过程就是线程间的协作。

Java中线程通信协作的 常见的两种方式：

一.syncrhoized加锁的线程的Object类的wait()/notify()/notifyAll()

二.ReentrantLock类加锁的线程的Condition类的await()/signal()/signalAll() 线程间直接的数据交换：

三.通过管道进行线程间通信：1）字节流；2）字符流同步方法和同步块，哪个是更好的选择？

同步块是更好的选择，因为它不会锁住整个对象（当然你也可以让它锁住整个对象）。同步方法会锁住整个对象，哪怕这个类中有多个不相关联的同步块，这通常会导致他们停止执行并需要等待获得这个对象上的锁。

同步块更要符合开放调用的原则，只在需要锁住的代码块锁住相应的对象，这样从侧面来说也可以避免死锁。

请知道一条原则：同步的范围越小越好。

当一个线程对共享的数据进行操作时，应使之成为一个”原子操作“，即在没有完成相关操作之前，不允许其他线程打断它，否则，就会破坏数据的完整性，必然会得到错误的处理结果，这就是线程的同步。

在多线程应用中，考虑不同线程之间的数据同步和防止死锁。当两个或多个线程之间同时等待对方释放资源的时候就会形成线程之间的死锁。为了防止死锁的发生，需要通过同步来实现线程安全。

线程互斥是指对于共享的进程系统资源，在各单个线程访问时的排它性。当有若干个线程都要使用某一共享资源时，任何时刻 多只允许一个线程去使用，其它要使用该资源的线程必须等待，直到占用资源者释放该资源。线程互斥可以看成是一种特殊的线程同步。

线程间的同步方法大体可分为两类：用户模式和内核模式。顾名思义，内核模式就是指利用系统内核对象的单一性来进行同步，使用时需要切换内核态与用户态，而用户模式就是不需要切换到内核态，只在用户态完成操作。

用户模式下的方法有：原子操作（例如一个单一的全局变量），临界区。内核模式下的方法有：事件，信号量，互斥量。

实现线程同步的方法

• 同步代码方法：sychronized 关键字修饰的方法同步代码块：
• sychronized 关键字修饰的代码块
• 使用特殊变量域volatile实现线程同步：volatile关键字为域变量的访问提供了一种免锁机制
• 使用重入锁实现线程同步：reentrantlock类是可冲入、互斥、实现了 lock接口的锁他与sychronized方法具有相同的基本行为和语义

在 java 虚拟机中，每个对象( Object 和 class )通过某种逻辑关联监视器,每个监视器和一个对象引用相关联，为了实现监视器的互斥功能，每个对象都关联着一把锁。

一旦方法或者代码块被 synchronized 修饰，那么这个部分就放入了监视器的

监视区域，确保一次只能有一个线程执行该部分的代码，线程在获取锁之前不允许执行该部分的代码

另外 java 还提供了显式监视器( Lock )和隐式监视器( synchronized )两种锁方案

这里区分一下：

（1） 如果使用的是无界队列 LinkedBlockingQueue，也就是无界队列的话，

没关系，继续添加任务到阻塞队列中等待执行，因为 LinkedBlockingQueue 可以近乎认为是一个无穷大的队列，可以无限存放任务

（2） 如果使用的是有界队列比如 ArrayBlockingQueue，任务首先会被添加到

ArrayBlockingQueue 中，ArrayBlockingQueue 满了，会根据

maximumPoolSize 的值增加线程数量，如果增加了线程数量还是处理不过来，ArrayBlockingQueue 继续满，那么则会使用拒绝策略

RejectedExecutionHandler 处理满了的任务，默认是 AbortPolicy 什么叫线程安全？servlet 是线程安全吗?

线程安全是编程中的术语，指某个方法在多线程环境中被调用时，能够正确地处理多个线程之间的共享变量，使程序功能正确完成。

Servlet 不是线程安全的，servlet 是单实例多线程的，当多个线程同时访问同一个方法，是不能保证共享变量的线程安全性的。

Struts2 的 action 是多实例多线程的，是线程安全的，每个请求过来都会 new 一个新的 action 分配给这个请求，请求完成后销毁。

SpringMVC 的 Controller 是线程安全的吗？不是的，和 Servlet 类似的处理流程。

Struts2 好处是不用考虑线程安全问题；Servlet 和 SpringMVC 需要考虑线程

安全问题，但是性能可以提升不用处理太多的 gc，可以使用 ThreadLocal 来处理多线程的问题。

方法一：使用安全类，比如 java.util.concurrent 下的类，使用原子类AtomicInteger

方法二：使用自动锁 synchronized。

方法三：使用手动锁 Lock。

手动锁 Java 示例代码如下：

1 Lock lock = new ReentrantLock(); 
2 lock. lock(); 
3 try {
4	System. out. println("获得锁");
5	} catch (Exception e) {
6	// TODO: handle exception
7	} finally {
8	System. out. println("释放锁");
9	lock. unlock();
10	}

每一个线程都是有优先级的，一般来说，高优先级的线程在运行时会具有优先 权，但这依赖于线程调度的实现，这个实现是和操作系统相关的(OS dependent)。我们可以定义线程的优先级，但是这并不能保证高优先级的线程 会在低优先级的线程前执行。线程优先级是一个 int 变量(从 1-10)，1 代表低 优先级，10 代表高优先级。 Java 的线程优先级调度会委托给操作系统去处理，所以与具体的操作系统优先 级有关，如非特别需要，一般无需设置线程优先级。

Java 的线程优先级调度会委托给操作系统去处理，所以与具体的操作系统优先级有关，如非特别需要，一般无需设置线程优先级。

这是一个非常刁钻和狡猾的问题。请记住：线程类的构造方法、静态块是被

new这个线程类所在的线程所调用的，而 run 方法里面的代码才是被线程自身所调用的。

如果说上面的说法让你感到困惑，那么我举个例子，假设 Thread2 中 new 了

Thread1，main 函数中 new 了 Thread2，那么：

（1） Thread2 的构造方法、静态块是 main 线程调用的，Thread2 的 run()方法是Thread2 自己调用的

（2） Thread1 的构造方法、静态块是 Thread2 调用的，Thread1 的 run()方法是Thread1 自己调用的

Dump文件是进程的内存镜像。可以把程序的执行状态通过调试器保存到dump 文件中。

在 Linux 下，你可以通过命令 kill -3 PID （Java 进程的进程 ID）来获取 Java 应用的 dump 文件。

在 Windows 下，你可以按下 Ctrl + Break 来获取。这样 JVM 就会将线程的 dump 文件打印到标准输出或错误文件中，它可能打印在控制台或者日志文件中，具体位置依赖应用的配置。

一个线程运行时发生异常会怎样？如果异常没有被捕获该线程将会停止执行。

Thread.UncaughtExceptionHandler是用于处理未捕获异常造成线程突然中断情况的一个内嵌接口。当一个未捕获异常将造成线程中断的时候，JVM 会使用

Thread.getUncaughtExceptionHandler()来查询线程的

UncaughtExceptionHandler 并将线程和异常作为参数传递给 handler 的 uncaughtException()方法进行处理。

• 线程的生命周期开销非常高消耗过多的

• CPU资源如果可运行的线程数量多于可用处理器的数量，那么有线程将会被闲置。大量空闲的线程会占用许多内存，给垃圾回收器带来压力，而且大量的线程在竞争CPU资源时还将产生其他性能的开销。

• 降低稳定性JVM 在可创建线程的数量上存在一个限制，这个限制值将随着平台的不同而不同，并且承受着多个因素制约，包括 JVM 的启动参数、Thread 构造函数中请求栈的大小，以及底层操作系统对线程的限制等。如果破坏了这些限制，那么可能抛出OutOfMemoryError 异常。

Java中垃圾回收有什么目的？什么时候进行垃圾回收？垃圾回收是在内存中存在没有引用的对象或超过作用域的对象时进行的。垃圾回收的目的是识别并且丢弃应用不再使用的对象来释放和重用资源。

不会，在下一个垃圾回调周期中，这个对象将是被可回收的。

也就是说并不会立即被垃圾收集器立刻回收，而是在下一次垃圾回收时才会释放其占用的内存。

1） 垃圾回收器（garbage colector）决定回收某对象时，就会运行该对象的finalize()方法；

finalize是Object类的一个方法，该方法在Object类中的声明protected void finalize() throws Throwable { }

在垃圾回收器执行时会调用被回收对象的finalize()方法，可以覆盖此方法来实现对其资源的回收。注意：一旦垃圾回收器准备释放对象占用的内存，将首先调用该对象的finalize()方法，并且下一次垃圾回收动作发生时，才真正回收对象占用的内存空间

2） GC本来就是内存回收了，应用还需要在finalization做什么呢？ 答案是大部分时候，什么都不用做(也就是不需要重载)。只有在某些很特殊的情况下，比如你调用了一些native的方法(一般是C写的)，可以要在finaliztion里去调用C的释放函数。

在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件：在单线程环境下不能改变程序运行的结果；存在数据依赖关系的不允许重排序需要注意的是：重排序不会影响单线程环境的执行结果，但是会破坏多线程的执行语义。

as-if-serial语义保证单线程内程序的执行结果不被改变，happensbefore关系保证正确同步的多线程程序的执行结果不被改变。as-if-serial语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。happens-before关系给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按 happens-before指定的顺序来执行的。

as-if-serial语义和happens-before这么做的目的，都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

在 Java 中，synchronized 关键字是用来控制线程同步的，就是在多线程的环境下，控制 synchronized 代码段不被多个线程同时执行。synchronized 可以修饰类、方法、变量。

另外，在 Java 早期版本中，synchronized属于重量级锁，效率低下，因为监视

器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的

线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方

对从 JVM 层面对synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。

synchronized关键字最主要的三种使用方式：

修饰实例方法: 作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁

修饰静态方法: 也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。修饰代码块: 指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定

对象的锁。

总结： synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。synchronized 关键字加到实例方法上是给对象实

例上锁。尽量不要使用 synchronized(String a) 因为JVM中，字符串常量池具

有缓存功能！下面我以一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！” 双重校验锁实现对象单例（线程安全）

1 public class Singleton {
2
3 private volatile static Singleton uniqueInstance;
4
5	private Singleton() {
6	}
7
8	public static Singleton getUniqueInstance() {
9	//先判断对象是否已经实例过，没有实例化过才进入加锁代码
10	if (uniqueInstance == null) {
11	//类对象加锁
12	synchronized (Singleton.class) {
13	if (uniqueInstance == null) {
14	uniqueInstance = new Singleton();
15	}
16	}
17	}
18	return uniqueInstance;
19	}
20	}

另外，需要注意 uniqueInstance 采用 volatile 关键字修饰也是很有必要。 uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance

= new Singleton(); 这段代码其实是分为三步执行：

1. 为 uniqueInstance 分配内存空间

2. 初始化 uniqueInstance

3. 将 uniqueInstance 指向分配的内存地址

但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用

getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。说一下 synchronized 底层实现原理？

synchronized是Java中的一个关键字，在使用的过程中并没有看到显示的加锁和解锁过程。因此有必要通过javap命令，查看相应的字节码文件。 synchronized 同步语句块的情况

1	public class SynchronizedDemo {
2	public void method() {
3	synchronized (this) {
4	System.out.println("synchronized 代码块");
5	}
6	}
7	}

通过JDK 反汇编指令 javap -c -v SynchronizedDemo

可以看出在执行同步代码块之前之后都有一个monitor字样，其中前面的是

monitorenter，后面的是离开monitorexit，不难想象一个线程也执行同步代码块，首先要获取锁，而获取锁的过程就是monitorenter ，在执行完代码块之后，要释放锁，释放锁就是执行monitorexit指令。

为什么会有两个monitorexit呢？

这个主要是防止在同步代码块中线程因异常退出，而锁没有得到释放，这必然会造成死锁（等待的线程永远获取不到锁）。因此 后一个monitorexit是保证在异常情况下，锁也可以得到释放，避免死锁。

仅有ACC_SYNCHRONIZED这么一个标志，该标记表明线程进入该方法时，需要monitorenter，退出该方法时需要monitorexit。

synchronized可重入的原理

重入锁是指一个线程获取到该锁之后，该线程可以继续获得该锁。底层原理维护一个计数器，当线程获取该锁时，计数器加一，再次获得该锁时继续加一，释放锁时，计数器减一，当计数器值为0时，表明该锁未被任何线程所持有，其它线程可以竞争获取锁。

很多 synchronized 里面的代码只是一些很简单的代码，执行时间非常快，此时等待的线程都加锁可能是一种不太值得的操作，因为线程阻塞涉及到用户态和内核态切换的问题。既然 synchronized 里面的代码执行得非常快，不妨让等待锁的线程不要被阻塞，而是在 synchronized 的边界做忙循环，这就是自旋。如果做了多次循环发现还没有获得锁，再阻塞，这样可能是一种更好的策略。

synchronized 锁升级原理：在锁对象的对象头里面有一个 threadid 字段，在第一次访问的时候 threadid 为空，jvm 让其持有偏向锁，并将 threadid 设置为其线程 id，再次进入的时候会先判断 threadid 是否与其线程 id 一致，如果

一致则可以直接使用此对象，如果不一致，则升级偏向锁为轻量级锁，通过自旋循环一定次数来获取锁，执行一定次数之后，如果还没有正常获取到要使用的对象，此时就会把锁从轻量级升级为重量级锁，此过程就构成了 synchronized 锁的升级。

锁的升级的目的：锁升级是为了减低了锁带来的性能消耗。在 Java 6 之后优化 synchronized 的实现方式，使用了偏向锁升级为轻量级锁再升级到重量级锁的方式，从而减低了锁带来的性能消耗。

（1） volatile 修饰变量

（2） synchronized 修饰修改变量的方法

（3） wait/notify

（4）while 轮询

不能。其它线程只能访问该对象的非同步方法，同步方法则不能进入。因为非静态方法上的 synchronized 修饰符要求执行方法时要获得对象的锁，如果已经进入A 方法说明对象锁已经被取走，那么试图进入 B 方法的线程就只能在等锁池

（注意不是等待池哦）中等待对象的锁。

（1）synchronized 是悲观锁，属于抢占式，会引起其他线程阻塞。（2）volatile 提供多线程共享变量可见性和禁止指令重排序优化。

（3）CAS 是基于冲突检测的乐观锁（非阻塞）

• 首先synchronized是Java内置关键字，在JVM层面，Lock是个Java类；
• synchronized 可以给类、方法、代码块加锁；而 lock 只能给代码块加锁。
• synchronized 不需要手动获取锁和释放锁，使用简单，发生异常会自动释放锁，不会造成死锁；而 lock 需要自己加锁和释放锁，如果使用不当没有 unLock()去释放锁就会造成死锁。
• 通过 Lock 可以知道有没有成功获取锁，而 synchronized 却无法办到。

synchronized 是和 if、else、for、while 一样的关键字，ReentrantLock 是类，这是二者的本质区别。既然 ReentrantLock 是类，那么它就提供了比

synchronized 更多更灵活的特性，可以被继承、可以有方法、可以有各种各样的类变量

synchronized 早期的实现比较低效，对比 ReentrantLock，大多数场景性能都

相差较大，但是在 Java 6 中对 synchronized 进行了非常多的改进。

相同点：两者都是可重入锁两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。

同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0 时才能释放锁。主要区别如下：

• ReentrantLock 使用起来比较灵活，但是必须有释放锁的配合动作；
• ReentrantLock 必须手动获取与释放锁，而 synchronized 不需要手动释放和开启锁；
• ReentrantLock 只适用于代码块锁，而 synchronized 可以修饰类、方法、变量等。
• 二者的锁机制其实也是不一样的。ReentrantLock 底层调用的是 Unsafe 的 park 方法加锁，synchronized 操作的应该是对象头中 mark word
• Java中每一个对象都可以作为锁，这是synchronized实现同步的基础： 普通同步方法，锁是当前实例对象
• 静态同步方法，锁是当前类的class对象
• 同步方法块，锁是括号里面的对象

对于可见性，Java 提供了 volatile 关键字来保证可见性和禁止指令重排。

volatile 提供 happens-before 的保证，确保一个线程的修改能对其他线程是可见的。当一个共享变量被 volatile 修饰时，它会保证