1.1 并行和并发有什么区别？

并发（concurrency）和并行（parallellism）是：

• 并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔发生。
• 并行是在不同实体上的多个事件，并发是在同一实体上的多个事件。比如在单核CPU系统上，只可能存在并发而不可能存在并行。
• 并行是在一台处理器上“同时”处理多个任务，在多台处理器上同时处理多个任务。如hadoop分布式集群

所以并发编程的目标是充分的利用处理器的每一个核，以达到最高的处理性能。那为什么并发就能充分利用cpu的执行能力

首先执行多个任务如果是串行执行那么cpu一定会存在等待一个任务执行完再去执行下一个任务，但是如果是并发开启多个线程去分别执行不同的任务的时候，这个时候便可以充分的利用cpu，多个线程进行切换去抢占cpu，cpu的空闲时间就会减少。

1.2 多线程 VS 高并发

多线程是完成任务的一种方法，高并发是系统运行的一种状态，通过多线程有助于系统承受高并发的状态的实现。

高并发是系统运行过程中遇到的一种“短时间内遇到大量的操作请求” 的情况，主要发生在web系统集中大量访问或者socket端口集中行收到大量请求（例如12306抢票；天猫双十一活动）。该情况会导致系统在这段时间内大量操作，例如对资源的请求，对数据库的集中操作等。如果并发处理不好，不仅降低了客户体验度（请求时间过长） ，同时可能导致宕机，系统停止工作等。如果想要系统适应高并发的状态，则需要从，硬件，软件，网络，系统架构，开发语言的选取，数据结构的运用，算法优化，数据库优化等。。。而多线程只是解决方案其中之一。

2. 线程和进程的区别？

进程：是执行中一段程序，即一旦程序被载入到内存中并准备执行，它就是一个进程。进程是表示资源分配的的基本概念，又是调度运行的基本单位，是系统中的并发执行的单位。

线程：单个进程中执行中每个任务就是一个线程。线程是进程中执行运算的最小单位。
一个线程只能属于一个进程，但是一个进程可以拥有多个线程。多线程处理就是允许一个进程中在同一时刻执行多个任务。

进程和线程的主要差别在于它们是不同的操作系统资源管理方式。进程有独立的地址空间，一个进程崩溃后，在保护模式下不会对其它进程产生影响，而线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量，但线程之间没有单独的地址空间，一个线程死掉就等于整个进程死掉，所以多进程的程序要比多线程的程序健壮，但在进程切换时，耗费资源较大，效率要差一些。但对于一些要求同时进行并且又要共享某些变量的并发操作，只能用线程，不能用进程。

• 1. 简而言之,一个程序至少有一个进程,一个进程至少有一个线程.**
• 2. 线程的划分尺度小于进程，使得多线程程序的并发性高。
• 3. 另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。
• 4. 线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。
• 5. 从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。
• 6. 线程和进程在使用上各有优缺点：
     线程执行开销小，但不利于资源的管理和保护；
     而进程正相反。
     同时，线程适合于在SMP机器上运行，而进程则可以跨机器迁移。

3. 守护线程是什么？

守护线程（即daemon thread），是个服务线程，准确地来说就是服务其他的线程，这是它的作用——而其他的线程只有一种，那就是用户线程。所以java里线程分2种，
1、守护线程，比如垃圾回收线程，就是最典型的守护线程。
2、用户线程，就是应用程序里的自定义线程。

将线程转换为守护线程可以通过调用Thread对象的setDaemon(true)方法来实现。在使用守护线程时需要注意一下几点：

(1) thread.setDaemon(true)必须在thread.start()之前设置，否则会跑出一个IllegalThreadStateException异常。你不能把正在运行的常规线程设置为守护线程。

(2) 在Daemon线程中产生的新线程也是Daemon的。

(3) 守护线程应该永远不去访问固有资源，如文件、数据库，因为它会在任何时候甚至在一个操作的中间发生中断

守护线程和用户线程的没啥本质的区别：唯一的不同之处就在于虚拟机的离开：如果用户线程已经全部退出运行了，只剩下守护线程存在了，虚拟机也就退出了。 因为没有了被守护者，守护线程也就没有工作可做了，也就没有继续运行程序的必要了。

4. 创建线程有哪几种方式？

一、继承Thread类创建线程类
二、通过Runnable接口创建线程类
三、通过Callable和Future创建线程

采用实现Runnable、Callable接口的方式创见多线程时，优势是：
线程类只是实现了Runnable接口或Callable接口，还可以继承其他类。
在这种方式下，多个线程可以共享同一个target对象，所以非常适合多个相同线程来处理同一份资源的情况，从而可以将CPU、代码和数据分开，形成清晰的模型，较好地体现了面向对象的思想。

劣势是：

编程稍微复杂，如果要访问当前线程，则必须使用Thread.currentThread()方法。

使用继承Thread类的方式创建多线程时优势是：

编写简单，如果需要访问当前线程，则无需使用Thread.currentThread()方法，直接使用this即可获得当前线程。

劣势是：

线程类已经继承了Thread类，所以不能再继承其他父类。

5. 说一下 runnable 和 callable 有什么区别？

相同点

• 都是接口
• 都可以编写多线程程序
• 都采用Thread.start()启动线程

不同点

• Runnable没有返回值；Callable可以返回执行结果，是个泛型，和Future、FutureTask配合可以用来获取异步执行的结果
• Callable接口的call()方法允许抛出异常；Runnable的run()方法异常只能在内部消化，不能往上继续抛

注：Callalbe接口支持返回执行结果，需要调用FutureTask.get()得到，此方法会阻塞主进程的继续往下执行，如果不调用不会阻塞。

Thread（抽象类） 和 runnable（接口）区别

• 1、由于Java不允许多继承，因此实现了Runnable接口可以再继承其他类，但是Thread明显不可以；
• 2、Runnable可以实现多个相同的程序代码的线程去共享同一个资源，而Thread并不是不可以，而是相比于Runnable来说，不太适合。
  比说，在实现runnable接口的类A中，定义一个变量B，然后使用new Thread(A).start()启动线程，通过多线程来共享A类中的变量B；但是通过Thread就不能这样做，每次new Thread类C，C中的变量D都是新的，不共享的。如果需要共享，则和继承runnable一样，在继承thread的类A中，定义一个变量B,然后然后使用new Thread(A).start()启动线程。
  其实我们从Thread源码中也可以看到，当以Thread方式去实现资源共享时，实际上源码内部是将thread向下转型为了Runnable，实际上内部依然是以Runnable形式去实现的资源共享

在程序开发中只要是多线程肯定永远以实现Runnable接口为主。

6. 线程有哪些状态？

Java中的线程的生命周期大体可分为5种状态。

image.png

• 1. 新建(NEW)：新创建了一个线程对象。
• 2. 可运行(RUNNABLE)：线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取cpu 的使用权 。
• 3. 运行(RUNNING)：可运行状态(runnable)的线程获得了cpu 时间片（timeslice） ，执行程序代码。
• 4. 阻塞(BLOCKED)：阻塞状态是指线程因为某种原因放弃了cpu 使用权，也即让出了cpu timeslice，暂时停止运行。直到线程进入可运行(runnable)状态，才有机会再次获得cpu timeslice 转到运行(running)状态。阻塞的情况分三种：
  • (一). 等待阻塞：运行(running)的线程执行o.wait()方法，JVM会把该线程放入等待队列(waitting queue)中。
  • (二). 同步阻塞：运行(running)的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入锁池(lock pool)中。
  • (三). 其他阻塞：运行(running)的线程执行Thread.sleep(long ms)或t.join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入可运行(runnable)状态。
• 5. 死亡(DEAD)：线程run()、main() 方法执行结束，或者因异常退出了run()方法，则该线程结束生命周期。死亡的线程不可再次复生。

7. sleep() 和 wait() 有什么区别？

• 1、这两个方法来自不同的类分别是，sleep来自Thread类，和wait来自Object类。

• 2、sleep() 和 wait() 的区别就是 调用sleep方法的线程不会释放对象锁，而调用wait() 方法会释放对象锁

sleep是Thread的静态类方法，谁调用的谁去睡觉，即使在a线程里调用了b的sleep方法，实际上还是a去睡觉，要让b线程睡觉要在b的代码中调用sleep。

wait()是Object类的方法，当一个线程执行到wait方法时，它就进入到一个和该对象相关的等待池，同时释放对象的机锁，使得其他线程能够访问，可以通过notify，notifyAll方法来唤醒等待的线程

sleep不出让系统资源；wait是进入线程等待池等待，出让系统资源，其他线程可以占用CPU。一般wait不会加时间限制，因为如果wait线程的运行资源不够，再出来也没用，要等待其他线程调用notify/notifyAll唤醒等待池中的所有线程，才会进入就绪队列等待OS分配系统资源。sleep(milliseconds)可以用时间指定使它自动唤醒过来，如果时间不到只能调用interrupt()强行打断。

Thread.Sleep(0)的作用是“触发操作系统立刻重新进行一次CPU竞争”。

• 3、使用范围：wait，notify和notifyAll只能在同步控制方法或者同步控制块里面使用，而sleep可以在任何地方使用
  synchronized(x){
  x.notify()
  //或者wait()
  }

• 4、sleep必须捕获异常，而wait，notify和notifyAll不需要捕获异常

8. notify()和 notifyAll()有什么区别？

如果线程调用了对象的 wait()方法，那么线程便会处于该对象的等待池中，等待池中的线程不会去竞争该对象的锁。
当有线程调用了对象的 notifyAll()方法（唤醒所有 wait 线程）或 notify()方法（只随机唤醒一个 wait 线程），被唤醒的的线程便会进入该对象的锁池中，锁池中的线程会去竞争该对象锁。也就是说，调用了notify后只要一个线程会由等待池进入锁池，而notifyAll会将该对象等待池内的所有线程移动到锁池中，等待锁竞争
优先级高的线程竞争到对象锁的概率大，假若某线程没有竞争到该对象锁，它还会留在锁池中，唯有线程再次调用 wait()方法，它才会重新回到等待池中。而竞争到对象锁的线程则继续往下执行，直到执行完了 synchronized 代码块，它会释放掉该对象锁，这时锁池中的线程会继续竞争该对象锁。
综上，所谓唤醒线程，另一种解释可以说是将线程由等待池移动到锁池，notifyAll调用后，会将全部线程由等待池移到锁池，然后参与锁的竞争，竞争成功则继续执行，如果不成功则留在锁池等待锁被释放后再次参与竞争。而notify只会唤醒一个线程。

notify可能会导致死锁，而notifyAll则不会

9. 线程的 run()和 start()有什么区别？

每个线程都有要执行的任务。线程的任务处理逻辑可以在Tread类的run实例方法中直接实现或通过该方法进行调用，因此

• run()相当于线程的任务处理逻辑的入口方法，它由Java虚拟机在运行相应线程时直接调用，而不是由应用代码进行调用。

• start()的作用是启动相应的线程。启动一个线程实际是请求Java虚拟机运行相应的线程，而这个线程何时能够运行是由线程调度器决定的。start()调用结束并不表示相应线程已经开始运行，这个线程可能稍后运行，也可能永远也不会运行。

10.创建线程池有哪几种方式？

Java通过Executors提供四种线程池，分别为：

• newCachedThreadPool：创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程，队列是SynchronousQueue<Runnable>；
• newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待，队列是LinkedBlockingQueue<Runnable>；
• newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行，队列是DelayedWorkQueue()；
• newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行，队列是LinkedBlockingQueue<Runnable>；

阿里的 Java开发手册，上面有线程池的一个建议：线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。Executors利用工厂模式向我们提供了4种线程池实现方式，但是并不推荐使用，原因是使用Executors创建线程池不会传入拒绝策略这个参数而使用默认值所以我们常常忽略这一参数，而且默认使用的参数会导致资源浪费，不可取。

说明：Executors 各个方法的弊端：
1）newFixedThreadPool 和 newSingleThreadExecutor：主要问题是堆积的请求处理队列可能会耗费非常大的内存，甚至 OOM，因为队列是无界阻塞队列LinkedBlockingQueue；

2）newCachedThreadPool 和 newScheduledThreadPool：主要问题是线程数最大数是 Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至 OOM。因为SynchronousQueue是一个内部只能包含一个元素的队列；

线程池源码解析见Java线程池
队列的介绍见Java容器

11. 线程池中 submit()和 execute()方法有什么区别？

• 1. 接收的参数不一样;submit callable，execute 是runnable
• 2. submit()有返回值，而execute()没有;
     例如，有个validation的task，希望该task执行完后告诉我它的执行结果，是成功还是失败，然后继续下面的操作。
• 3. submit()可以进行Exception处理;
     例如，如果task里会抛出checked或者unchecked exception，而你又希望外面的调用者能够感知这些exception并做出及时的处理，那么就需要用到submit，通过对Future.get()进行抛出异常的捕获，然后对其进行处理。

12.1 在 java 程序中怎么保证多线程的运行安全？

一、线程安全在三个方面体现

1.原子性：提供互斥访问，同一时刻只能有一个线程对数据进行操作，（atomic,synchronized）；

2.可见性：一个线程对主内存的修改可以及时地被其他线程看到，（synchronized,volatile）；

3.有序性：一个线程观察其他线程中的指令执行顺序，由于指令重排序，该观察结果一般杂乱无序，（happens-before原则）。

当然由于synchronized和Lock保证每个时刻只有一个线程执行同步代码，所以是线程安全的，也可以实现这一功能，但是由于线程是同步执行的，所以会影响效率。

原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。JDK里面提供了很多atomic类，AtomicInteger,AtomicLong,AtomicBoolean等等。它们是通过CAS完成原子性

可见性：指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取共享变量时，它会去内存中读取新值。

普通的共享变量不能保证可见性，因为普通共享变量被修改后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。

更新主存的步骤：当前线程将其他线程的工作内存中的缓存变量的缓存行设置为无效，然后当前线程将变量的值跟新到主存，更新成功后将其他线程的缓存行更新为新的主存地址

其他线程读取变量时，发现自己的缓存行无效，它会等待缓存行对应的主存地址被更新之后，然后去对应的主存读取最新的值。

有序性：即程序执行的顺序按照代码的先后顺序执行。
在Java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。
可以通过volatile关键字来保证一定的“有序性”。

12.2 在 java 程序中如何保证多个线程的执行顺序？

方法一：创建一个单线程线程池

//创建只有一根线程的线程池，保证所有任务按照指定顺序执行
        ExecutorService executorService = Executors.newSingleThreadExecutor();
        executorService.submit(new A());
        executorService.submit(new B());
        executorService.submit(new C());
        executorService.shutdown();

方法二：使用join()方法，等前一个线程执行完毕，下一个线程才能执行

当调用了t.join()，就必须要等待线程t执行完毕后，才能继续执行其他线程。这里其实是运用了Java中最顶级对象Object提供的方法wait()。wait(）方法用于线程间通信，它的含义是通知一个线程等待一下，让出CPU资源，注意这里是会放弃已经占有的资源的。直到t线程执行完毕，再调用notify()唤醒当前正在运行的线程。

public static void main(String[] args) throws InterruptedException {
        Thread thread1 = new Thread(new A());
        thread1.start();
        thread1.join();
        Thread thread2 = new Thread(new B());
        thread2.start();
        thread2.join();
        Thread thread3 = new Thread(new C());
        thread3.start();
    }

12.3 辨别线程安全与线程不安全

我们在Java中常常会有某个对象是线程安全的，另一个对象是线程不安全的，那么怎么判断这些对象是线程安全不安全的呢？是什么决定的线程安全问题呢？

线程安全问题都是由全局变量及静态变量引起的。
若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时对全局变量（静态变量）执行写操作——并发访问资源，一般都需要考虑线程同步，否则的话就可能影响线程安全。

那么怎么解决多线程并发访问资源的安全问题呢？
通常有三种方式：同步代码块synchronized 、同步方法synchronized和锁机制(Lock)

所以，一个对象是不是线程安全的，直接看其有没有对全局变量做写操作就可以，如果有，则继续看其写操作时有没有加锁Lock（或者同步），如果有的话，就是线程安全的，如果没有的话，就是线程不安全的。

13. 多线程锁的升级原理是什么？

在Java中，锁共有4种状态，级别从低到高依次为：无状态锁，偏向锁，轻量级锁和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级。

偏向锁
偏向锁的核心思想就是锁会偏向第一个获取它的线程，在接下来的执行过程中该锁没有其他的线程获取，则持有偏向锁的线程永远不需要再进行同步。

当一个线程访问同步块并获取锁的时候，会在对象头和栈帧中的锁记录里存储偏向的线程 ID，以后该线程在进入和退出同步块时不需要进行 CAS 操作来加锁和解锁，只需要检查当前 Mark Word 中存储的线程是否为当前线程，如果是，则表示已经获得对象锁；否则，需要测试 Mark Word 中偏向锁的标志是否为1，如果没有则使用 CAS 操作竞争锁，如果设置了，则尝试使用 CAS 将对象头的偏向锁指向当前线程。

需要注意的是，偏向锁使用一种等待竞争出现才释放锁的机制，所以当有其他线程尝试获得锁时，才会释放锁。偏向锁的撤销，需要等到安全点。它首先会暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果不处于活动状态，则将对象头设置为无锁状态；如果依然活动，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向其他线程，要么恢复到无锁或者标记对象不合适作为偏向锁（膨胀为轻量级锁），最后唤醒暂停的线程。

轻量级锁
线程在执行同步块之前，JVM会现在当前线程的栈帧中创建用于储存锁记录的空间（LockRecord），并将对象头的Mark Word信息复制到锁记录中。然后线程尝试使用 CAS 将对象头的MarkWord替换为指向锁记录的指针。如果成功，当前线程获得锁，并且对象的锁标志位转变为“00”，如果失败，表示其他线程竞争锁，当前线程便会尝试自旋获取锁。如果有两条以上的线程竞争同一个锁，那么轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态变为“10”，MarkWord中储存的就是指向重量级锁（互斥量）的指针，后面等待的线程也要进入阻塞状态。

轻量级锁解锁时，同样通过CAS操作将对象头换回来。如果成功，则表示没有竞争发生。如果失败，说明有其他线程尝试过获取该锁，锁同样会膨胀为重量级锁。在释放锁的同时，唤醒被挂起的线程。

重量级锁
重量级锁（Heavyweight Lock）是将程序运行交出控制权，将线程挂起，由操作系统来负责线程间的调度，负责线程的阻塞和执行。这样会出现频繁地对线程运行状态的切换，线程的挂起和唤醒，消耗大量的系统资源，导致性能低下。

最后看一下，锁升级的图示过程：

image.png

14. 什么是死锁？

死锁可以这样理解，就是互相不让步不放弃，同时需要对方的资源。造成互相不满足资源需求，也不放弃自身已有资源。死锁就这样了。

死锁是指多个进程因竞争资源而造成的一种僵局（互相等待），若无外力作用，这些进程都将无法向前推进。

死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去，如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。
产生死锁的原因主要是：
　　（1） 因为系统资源不足。
　　（2） 进程运行推进的顺序不合适。
　　（3） 资源分配不当等。
产生死锁的四个必要条件：
　　（1） 互斥条件：一个资源每次只能被一个进程使用。
　　（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
　　（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
　　（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
　　这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之
　　一不满足，就不会发生死锁。

15. 怎么防止死锁？

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态
的情况下占用资源。因此，对资源的分配要给予合理的规划。

预防死锁，预先破坏产生死锁的四个条件。互斥不可能破坏，所以有如下三种方法：
1、破坏请求和保持条件，
进程必须等所有要请求的资源都空闲时才能申请资源，这种方法会使资源浪费严重(有些资源可能仅在运行初期或结束时才使用，甚至根本不使用)。
允许进程获取初期所需资源后，便开始运行，运行过程中再逐步释放自己占有的资源，比如有一个进程的任务是把数据复制到磁盘中再打印，前期只需获得磁盘资源而不需要获得打印机资源，待复制完毕后再释放掉磁盘资源。这种方法比第一种方法好，会使资源利用率上升。
2、破坏不可抢占条件
这种方法代价大，实现复杂。
3、破坏循坏等待条件
对各进程请求资源的顺序做一个规定，避免相互等待。这种方法对资源的利用率比前两种都高，但是前期要为设备指定序号，新设备加入会有一个问题，其次对用户编程也有限制。

死锁，基本就是资源不够，互相需要对方资源却不肯放弃自身资源。N线程访问N资源，为了避免死锁，可以为其加锁并指定获取锁的顺序，这样线程按照顺序加锁访问资源，依次使用依次释放，可以避免死锁。

使用多线程的时候，一种非常简单的避免死锁的方式就是：指定获取锁的顺序，并强制线程按照指定的顺序获取锁。因此，如果所有的线程都是以同样的顺序加锁和释放锁，就不会出现死锁了。可以确保N个线程可以访问N个资源同时又不导致死锁了。

16. ThreadLocal 是什么？有哪些使用场景？

16.1 概述

ThreadLocal，即线程变量，是一个以 ThreadLocal 对象为键、任意对象为值的存储结构。
ThreadLocal是各线程将值存入该线程的map中，以ThreadLocal自身作为key，需要用时获得的是该线程之前存入的值，各个线程的数据互不干扰。如果存入的是共享变量，那取出的也是共享变量，并发问题还是存在的。

16.2 底层原理

ThreadLocal 底层是通过ThreadLocalMap数据结构来实现的，每个线程中都有一个ThreadLocalMap数据结构。

在ThreadLoalMap中，也是初始化一个大小16的Entry数组，Entry对象用来保存每一个key-value键值对，只不过这里的key永远都是ThreadLocal对象，ThreadLoalMap的Entry是继承WeakReference，和HashMap很大的区别是，Entry中没有next字段，所以就不存在链表的情况了。

image.png

因为没有链表，所以hash冲突时，会多次寻址。

16.3 内存泄漏

从上面介绍，我们知道每个Thread中都存在一个ThreadLocalMap，ThreadLocalMap的key为threadLocal实例，value为任意对象。
####### 16.3.1 原因
ThreadLocal为线程变量，即在线程的生命周期中这个变量都不会被显示的回收，但是我们通常只会在一段时间内使用这个变量，不能被回收的话，太浪费内存空间了，同时，如果是下面这种数据库连接和Session管理应用的话，线程一直存活，那threadlocal一直不能被释放，会发送内存泄漏。

java为了防止出现这种情况，把ThreadLocalMap的key设为弱引用指向threadlocal，如下

static class ThreadLocalMap {
     
        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
}

当把threadlocal实例置为null以后，没有任何强引用指向threadlocal实例，所以threadlocal就可以顺利被gc回收。

现在threadlocal能被及时回收了，但是ThreadLocalMap中的value却没有被回收，因为存在一条从current thread连接过来的强引用，而这块value永远不会被访问到， 所以存在着内存泄露。
只有当前thread结束以后，current thread就不会存在栈中，强引用断开，Current Thread, ThreadLocalMap, value将全部被GC回收。
####### 16.3.2 解决方案
当线程的某个ThreadLocal使用完了，马上调用threadlocal的remove方法，那就啥事没有了！

16.4 使用场景

ThreadLocal是用来维护本线程的变量的，并不能解决共享变量的并发问题。
ThreadLocal既然不能解决并发问题，那么它适用的场景是什么呢？
ThreadLocal的主要用途是为了保持线程自身对象和避免参数传递，主要适用场景是按线程多实例（每个线程对应一个实例）的对象的访问，并且这个对象很多地方都要用到。
最常见的ThreadLocal使用场景为 用来解决数据库连接、Session管理等。如：

#数据库连接：
private static ThreadLocal<Connection> connectionHolder = new ThreadLocal<Connection>() {  
    public Connection initialValue() {  
        return DriverManager.getConnection(DB_URL);  
    }  
};  
  
public static Connection getConnection() {  
    return connectionHolder.get();  
}  

#Session管理：
private static final ThreadLocal threadSession = new ThreadLocal();  
  
public static Session getSession() throws InfrastructureException {  
    Session s = (Session) threadSession.get();  
    try {  
        if (s == null) {  
            s = getSessionFactory().openSession();  
            threadSession.set(s);  
        }  
    } catch (HibernateException ex) {  
        throw new InfrastructureException(ex);  
    }  
    return s;  
}  

个人认为使用ThreadLocal的场景最好满足两个条件，一是该对象不需要在多线程之间共享；二是该对象需要在线程内被传递

17. 说一下 synchronized 底层实现原理？

synchronized的语义底层是通过一个monitor的对象来完成。
其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。

涉及两条指令：（1）monitorenter

每个对象有一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程如下：

1、如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。

2、如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1。

3、如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权。

（2）monitorexit

执行monitorexit的线程必须是objectref所对应的monitor的所有者。

指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个
monitor 的所有权。

18. synchronized 和 volatile 的区别是什么？

首先需要理解线程安全的两个方面：执行控制和内存可见。

执行控制的目的是控制代码执行（顺序）及是否可以并发执行。

内存可见控制的是线程执行结果在内存中对其它线程的可见性。根据Java内存模型
的实现，线程在具体执行时，会先拷贝主存数据到线程本地（CPU缓存），操作完成后再把结果从线程本地刷到主存。

synchronized关键字解决的是执行控制的问题，它会阻止其它线程获取当前对象的监控锁，这样就使得当前对象中被synchronized关键字保护的代码块无法被其它线程访问，也就无法并发执行。更重要的是，synchronized还会创建一个内存屏障，内存屏障指令保证了所有CPU操作结果都会直接刷到主存中，从而保证了操作的内存可见性，同时也使得先获得这个锁的线程的所有操作，都happens-before于随后获得这个锁的线程的操作。

volatile关键字解决的是内存可见性的问题，会使得所有对volatile变量的读写都会直接刷到主存，即保证了变量的可见性。这样就能满足一些对变量可见性有要求而对读取顺序没有要求的需求。

区别
volatile本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取； synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的
volatile仅能实现变量的修改可见性，不能保证原子性；而synchronized则可以保证变量的修改可见性和原子性
volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。
volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化

19. synchronized 和 Lock 有什么区别？

1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；

2）synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；

3）Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；

4）通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。

5）Lock可以提高多个线程进行读操作的效率。

在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

55. synchronized 和 ReentrantLock 区别是什么？

ReenTrantLock可重入锁（和synchronized的区别）总结

可重入性：

从名字上理解，ReenTrantLock的字面意思就是再进入的锁，其实synchronized关键字所使用的锁也是可重入的，两者关于这个的区别不大。两者都是同一个线程每进入一次，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。

锁的实现：

Synchronized是依赖于JVM实现的，而ReenTrantLock是JDK实现的，有什么区别，说白了就类似于操作系统来控制实现和用户自己敲代码实现的区别。前者的实现是比较难见到的，后者有直接的源码可供阅读。

性能的区别：

在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。

功能区别：

便利性：很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。

锁的细粒度和灵活度：很明显ReenTrantLock优于Synchronized

ReenTrantLock独有的能力：

1. ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。

2. ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。

3. ReenTrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。

ReenTrantLock实现的原理：
简单来说，ReenTrantLock的实现是一种自旋锁，通过循环调用CAS操作来实现加锁。它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设计的关键钥匙。

20. 说一下 atomic 的原理？

在多线程的场景中，我们需要保证数据安全，就会考虑同步的方案，通常会使用synchronized或者lock来处理，使用了synchronized意味着内核态的一次切换。这是一个很重的操作。

有没有一种方式，可以比较便利的实现一些简单的数据同步，比如计数器等等。concurrent包下的atomic提供我们这么一种轻量级的数据同步的选择。

优缺点
CAS相对于其他锁，不会进行内核态操作，有着一些性能的提升。但同时引入自旋，当锁竞争较大的时候，自旋次数会增多。cpu资源会消耗很高。

换句话说，CAS+自旋适合使用在低并发有同步数据的应用场景。