1 java多线程（非常重要）
1.1. 线程
线程和进程的区别？
线程是CPU调度的最小单位，一个进程中可以包含多个线程，在Android中，一个进程通常是一个App，App中会有一个主线程，主线程可以用来操作界面元素，如果有耗时的操作，必须开启子线程执行，不然会出现ANR，除此以外，进程间的数据是独立的，线程间的数据可以共享。
java多线程实现方式主要有：
-
继承Thread
优点 ： 方便传参，可以在子类添加成员变量，通过方法设置参数或构造函数传参。
缺点：
1.因为Java不支持多继承，所以继承了Thread类以后，就无法继承其他类。
2.每次都要新建一个类，不支持通过线程池操作，创建和销毁线程对资源的开销比较大。
3.从代码结构上讲，为了启动一个线程任务，都要创建一个类，耦合性太高。
4.无法获取线程任务的返回结果。Thread syncTask = new Thread() { @Override public void run() { // 执行耗时操作 } }; syncTask.start();//启动线程 -
实现Runnable
优点 ： 此方式可以继承其他类。也可以使用线程池管理，节约资源。创建线程代码的耦合性较低。推荐使用此种方式创建线程。
缺点： 不方便传参，只能使用主线程中用final修饰的变量。其次是无法获取线程任务的返回结果。//写法1：集成Runnable接口定义任务类 public class ThreadTask implements Runnable { @Override public void run() { while(true) { System.out.println(Thread.currentThread().getName()+" is running..."); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } } } } //在其他地方使用 new Thread(new ThreadTask ()).start(); //写法2：匿名内部类写法 new Thread(new Runnable() { @Override public void run() { //做操作 } }).start(); -
实现Callable
此种方式创建线程底层源码也是使用实现Runnable接口的方式实现的，所以不是一种新的创建线程的方式，只是在实现Runnable接口方式创建线程的基础上，同时实现了Future接口，实现有返回值的创建线程。Runnable 与 Callable的区别：
1. Runnable是在JDK1.0的时候提出的多线程的实现接口，而Callable是在JDK1.5之后提出的； 2. Runnable 接口之中只提供了一个run（）方法，并且没有返回值； 3. Callable接口提供有call()，可以有返回值；扩展：
Callable接口支持返回执行结果，此时需要调用FutureTask.get()方法实现，此方法会阻塞主线程直到获取‘将来’结果； 当不调用此方法时，主线程不会阻塞public class CallableImpl implements Callable<String> { public CallableImpl(String acceptStr) { this.acceptStr = acceptStr; } private String acceptStr; @Override public String call() throws Exception { // 任务阻塞 1 秒 Thread.sleep(1000); return this.acceptStr + " append some chars and return it!"; } public static void main(String[] args) throws ExecutionException, InterruptedException { Callable<String> callable = new CallableImpl("my callable test!"); FutureTask<String> task = new FutureTask<>(callable); long beginTime = System.currentTimeMillis(); // 创建线程 new Thread(task).start(); // 调用get()阻塞主线程，反之，线程不会阻塞 String result = task.get(); long endTime = System.currentTimeMillis(); System.out.println("hello : " + result); System.out.println("cast : " + (endTime - beginTime) / 1000 + " second!"); } } //执行结果 hello : my callable test! append some chars and return it! cast : 1 second!总结：
根据Oracle提供的JAVA官方文档的说明，Java创建线程的方法只有两种方式，即继承Thread类和实现Runnable接口。其他所有创建线程的方式，底层都是使用这两种方式中的一种实现的，比如通过线程池、通过匿名类、通过lambda表达式、通过Callable接口等等，全是通过这两种方式中的一种实现的。所以我们在掌握线程创建的时候，必须要掌握的只有这两种，通过文章中优缺点的分析，这两种方法中，最为推荐的就是实现Runnable接口的方式去创建线程。
1.2. 线程的状态有哪些？
Java中定义线程的状态有6种，可以查看Thread类的State枚举：
public static enum State
{
NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED;
private State() {}
}
初始（NEW）：新创建了一个线程对象，还没调用start方法；
运行（RUNNABLE）：java线程中将就绪（ready）和运行中（running）统称为运行（RUNNABLE）。线程创建后调用了该对象的start方法，此时处于就绪状态，当获得CPU时间片后变为运行中状态；
阻塞（BLOCKED）：表现线程阻塞于锁；
等待（WAITING）：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）；
超时等待（TIMED_WAITING）：该状态不同于WAITING，它可以在指定时间后自行返回；
终止（TERMINATED）：表示该线程已经执行完毕。
状态详细说明：
-
初始状态(NEW)
实现Runnable接口和继承Thread可以得到一个线程类，new一个实例出来，线程就进入了初始状态。 -
就绪状态(RUNNABLE之READY)
就绪状态只是说你资格运行，调度程序没有挑选到你，你就永远是就绪状态。
调用线程的start()方法，此线程进入就绪状态。
当前线程sleep()方法结束，其他线程join()结束，等待用户输入完毕，某个线程拿到对象锁，这些线程也将进入就绪状态。
当前线程时间片用完了，调用当前线程的yield()方法，当前线程进入就绪状态。
锁池里的线程拿到对象锁后，进入就绪状态。运行中状态(RUNNABLE之RUNNING)
线程调度程序从可运行池中选择一个线程作为当前线程时线程所处的状态。这也是线程进入运行状态的唯一的一种方式。 -
阻塞状态(BLOCKED)
阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块(获取锁)时的状态。 -
等待(WAITING)
处于这种状态的线程不会被分配CPU执行时间，它们要等待被显式地唤醒，否则会处于无限期等待的状态。 -
超时等待(TIMED_WAITING)
处于这种状态的线程不会被分配CPU执行时间，不过无须无限期等待被其他线程显示地唤醒，在达到一定时间后它们会自动唤醒。 -
终止状态(TERMINATED)
当线程的run()方法完成时，或者主线程的main()方法完成时，我们就认为它终止了。这个线程对象也许是活的，但是它已经不是一个单独执行的线程。线程一旦终止了，就不能复生。
在一个终止的线程上调用start()方法，会抛出java.lang.IllegalThreadStateException异常。
1.3. 线程的状态转换及控制
主要由这几个方法来控制：sleep、join、yield、wait、notify以及notifyAll。
wait() / notify() / notifyAll()
wait()，notify()，notifyAll() 是定义在Object类的实例方法，用于控制线程状态，三个方法都必须在synchronized 同步关键字所限定的作用域中调用（只能在同步控制方法或者同步控制块中使用），否则会报错 java.lang.IllegalMonitorStateException。
join() / sleep() / yield()
join()
如果线程A调用了线程B的join方法，线程A将被阻塞，等待线程B执行完毕后线程A才会被执行。这里需要注意一点的是，join方法必须在线程B的start方法调用之后调用才有意义。join方法的主要作用就是实现线程间的同步，它可以使线程之间的并行执行变为串行执行。
sleep()
当线程A调用了 sleep方法，则线程A将被阻塞，直到指定睡眠的时间到达后，线程A才会重新被唤起，进入就绪状态。
public class Test {
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
System.out.println(Thread.currentThread().getName() + "---" + i);
try {
Thread.sleep(1000); // 阻塞当前线程1s
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
yield() 当线程A调用了yield方法，它可以暂时放弃处理器，但是线程A不会被阻塞，而是进入就绪状态。执行了yield方法的线程什么时候会继续运行由线程调度器来决定。
public class YieldThread extends Thread {
@Override
public void run() {
for (int i = 0; i < 10; i++) {
System.out.println(Thread.currentThread().getName() + "---" + i);
// 主动放弃
Thread.yield();
}
}
}
sleep方法和wait方法的区别是什么？
wait方法既释放cpu，又释放锁。 sleep方法只释放cpu，但是不释放锁。
sleep 方法是Thread类的一个静态方法，其作用是使运行中的线程暂时停止指定的毫秒数，从而该线程进入阻塞状态并让出处理器，将执行的机会让给其他线程。但是这个过程中监控状态始终保持，当sleep的时间到了之后线程会自动恢复。
wait 方法是Object类的方法，它是用来实现线程同步的。当调用某个对象的wait方法后，当前线程会被阻塞并释放同步锁，直到其他线程调用了该对象的 notify 方法或者 notifyAll 方法来唤醒该线程。所以 wait 方法和 notify(或notifyAll)应当成对出现以保证线程间的协调运行。
1.4. Java如何正确停止线程
注意
Java中线程的stop()、suspend()、resume()三个方法都已经被弃用，所以不再使用stop()方法停止线程。
如何停止线程：
我们只能调用线程的interrupt()方法通知系统停止线程，并不能强制停止线程。线程能否停止，何时停止，取决于系统。
1.5 线程池(非常重要)
线程池的地位十分重要，基本上涉及到跨线程的框架都使用到了线程池，比如说OkHttp、RxJava、LiveData以及协程等。
与新建一个线程相比，线程池的特点？
节省开销： 线程池中的线程可以重复利用。
速度快：任务来了就能开始，省去创建线程的时间。
线程可控：线程数量可空和任务可控。
功能强大：可以定时和重复执行任务。
ExecutorService简介
通常来说我们说到线程池第一时间想到的就是它：ExecutorService，它是一个接口，其实如果要从真正意义上来说，它可以叫做线程池的服务，因为它提供了众多接口api来控制线程池中的线程，而真正意义上的线程池就是：ThreadPoolExecutor，它实现了ExecutorService接口，并封装了一系列的api使得它具有线程池的特性，其中包括工作队列、核心线程数、最大线程数等。
线程池(ThreadPoolExecutor)中的几个参数是什么意思？
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {//...}
参数解释如下(重要)：
corePoolSize：核心线程数量，不会释放。
maximumPoolSize：允许使用的最大线程池数量，非核心线程数量，闲置时会释放。
keepAliveTime：闲置线程允许的最大闲置时间。它起作用必须在一个前提下，就是当线程池中的线程数量超过了corePoolSize时，它表示多余的空闲线程的存活时间，即：多余的空闲线程在超过keepAliveTime时间内没有任务的话则被销毁。而这个主要应用在缓存线程池中
unit：闲置时间的单位。
workQueue：阻塞队列，用来存储已经提交但未被执行的任务，不同的阻塞队列有不同的特性。
threadFactory：线程工厂，用来创建线程池中的线程，通常用默认的即可
handler：通常叫做拒绝策略，1、在线程池已经关闭的情况下 2、任务太多导致最大线程数和任务队列已经饱和，无法再接收新的任务 。在上面两种情况下，只要满足其中一种时，在使用execute()来提交新的任务时将会拒绝，而默认的拒绝策略是抛一个RejectedExecutionException异常
上面的参数理解起来都比较简单，不过workQueue这个任务队列却要再次说明一下，它是一个BlockingQueue<Runnable>对象，而泛型则限定它是用来存放Runnable对象的，刚刚上面讲了，不同的线程池它的任务队列实现肯定是不一样的，所以，保证不同线程池有着不同的功能的核心就是这个workQueue的实现了，细心的会发现在刚刚的用来创建线程池的工厂方法中，针对不同的线程池传入的workQueue也不一样，五种线程池分别用的是什么BlockingQueue：
1、newFixedThreadPool()—>LinkedBlockingQueue 无界的队列
2、newSingleThreadExecutor()—>LinkedBlockingQueue 无界的队列
3、newCachedThreadPool()—>SynchronousQueue 直接提交的队列
4、newScheduledThreadPool()—>DelayedWorkQueue 等待队列
5、newSingleThreadScheduledExecutor()—>DelayedWorkQueue 等待队列
实现了BlockingQueue接口的队列还有：ArrayBlockingQueue（有界的队列）、PriorityBlockingQueue（优先级队列）。这些队列的详细作用就不多介绍了。
线程池的种类有哪些:五种功能不一样的线程池：
这样创建线程池的话，我们需要配置一堆东西，非常麻烦。所以，官方也不推荐使用这种方法来创建线程池，而是推荐使用Executors的工厂方法来创建线程池，Executors类是官方提供的一个工厂类，它里面封装好了众多功能不一样的线程池（但底层实现还是通过ThreadPoolExecutor），从而使得我们创建线程池非常的简便，主要提供了如下五种功能不一样的线程池：
newCachedThreadPool() ：返回一个可以根据实际情况调整线程池中线程的数量的线程池。即该线程池中的线程数量不确定，是根据实际情况动态调整的。
newFixedThreadPool() ：线程池只能存放指定数量的线程池，线程不会释放，可重复利用。
newSingleThreadExecutor() ：单线程的线程池。即每次只能执行一个线程任务，多余的任务会保存到一个任务队列中，等待这一个线程空闲，当这个线程空闲了再按FIFO方式顺序执行任务队列中的任务。
newScheduledThreadPool() ：可定时和重复执行的线程池。
newSingleThreadScheduledExecutor()：同上。和上面的区别是该线程池大小为1，而上面的可以指定线程池的大小。
通过Executors的工厂方法来获取：
ExecutorService fixedThreadPool = Executors.newFixedThreadPool(5);
ExecutorService singleThreadPool = Executors.newSingleThreadExecutor();
ExecutorService cachedThreadPool = Executors.newCachedThreadPool();
ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(5);
ScheduledExecutorService singleThreadScheduledPool = Executors.newSingleThreadScheduledExecutor();
通过Executors的工厂方法来创建线程池极其简便，其实它的内部还是通过new ThreadPoolExecutor(…)的方式创建线程池的，我们看一下这些工厂方法的内部实现：
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>()));
}
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
线程池ThreadPoolExecutor的使用
使用线程池，其中涉及到一个极其重要的方法，即：
execute(Runnable command)
该方法意为执行给定的任务，该任务处理可能在新的线程、已入池的线程或者正调用的线程，这由ThreadPoolExecutor的实现决定。
五种线程池使用举例：
-
newFixedThreadPool 创建一个固定线程数量的线程池，示例为：
创建了一个线程数为3的固定线程数量的线程池，同理该线程池支持的线程最大并发数也是3，而我模拟了10个任务让它处理，执行的情况则是首先执行前三个任务，后面7个则依次进入任务队列进行等待，执行完前三个任务后，再通过FIFO的方式从任务队列中取任务执行，直到最后任务都执行完毕。ExecutorService fixedThreadPool = Executors.newFixedThreadPool(3); for (int i = 1; i <= 10; i++) { final int index = i; fixedThreadPool.execute(new Runnable() { @Override public void run() { String threadName = Thread.currentThread().getName(); Log.v("zxy", "线程："+threadName+",正在执行第" + index + "个任务"); try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } } }); } -
newSingleThreadExecutor
创建一个只有一个线程的线程池，每次只能执行一个线程任务，多余的任务会保存到一个任务队列中，等待线程处理完再依次处理任务队列中的任务，示例为：ExecutorService singleThreadPool = Executors.newSingleThreadExecutor(); for (int i = 1; i <= 10; i++) { final int index = i; singleThreadPool.execute(new Runnable() { @Override public void run() { String threadName = Thread.currentThread().getName(); Log.v("zxy", "线程："+threadName+",正在执行第" + index + "个任务"); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } } }); } -
newCachedThreadPool
创建一个可以根据实际情况调整线程池中线程的数量的线程池，为了体现该线程池可以自动根据实现情况进行线程的重用，而不是一味的创建新的线程去处理任务，我设置了每隔1s去提交一个新任务，这个新任务执行的时间也是动态变化的，示例为ExecutorService cachedThreadPool = Executors.newCachedThreadPool(); for (int i = 1; i <= 10; i++) { final int index = i; try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } cachedThreadPool.execute(new Runnable() { @Override public void run() { String threadName = Thread.currentThread().getName(); Log.v("zxy", "线程：" + threadName + ",正在执行第" + index + "个任务"); try { long time = index * 500; Thread.sleep(time); } catch (InterruptedException e) { e.printStackTrace(); } } }); } -
newScheduledThreadPool
创建一个可以定时或者周期性执行任务的线程池，示例为：ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(3); //延迟2秒后执行该任务 scheduledThreadPool.schedule(new Runnable() { @Override public void run() { } }, 2, TimeUnit.SECONDS); //延迟1秒后，每隔2秒执行一次该任务 scheduledThreadPool.scheduleAtFixedRate(new Runnable() { @Override public void run() { } }, 1, 2, TimeUnit.SECONDS); -
newSingleThreadScheduledExecutor
创建一个可以定时或者周期性执行任务的线程池，该线程池的线程数为1，示例为ScheduledExecutorService singleThreadScheduledPool = Executors.newSingleThreadScheduledExecutor(); //延迟1秒后，每隔2秒执行一次该任务 singleThreadScheduledPool.scheduleAtFixedRate(new Runnable() { @Override public void run() { String threadName = Thread.currentThread().getName(); Log.v("zxy", "线程：" + threadName + ",正在执行"); } },1,2,TimeUnit.SECONDS);这个和上面的没什么太大区别，只不过是线程池内线程数量的不同，效果为：每隔2秒就会执行一次该任务
自定义线程池ThreadPoolExecutor（自行了解）
线程池的停止
关于线程池的停止，ExecutorService为我们提供了两个方法：shutdown和shutdownNow，这两个方法各有不同，可以根据实际需求方便的运用，如下：
1、shutdown() 平滑的关闭线程池。（如果还有未执行完的任务，就等待它们执行完）。
2、shutdownNow() 简单粗暴的关闭线程池。（没有执行完的任务也直接关闭）。
线程池的工作流程
简单说：
任务来了，优先考虑核心线程。
核心线程满了，进入阻塞队列。
阻塞队列满了，考虑非核心线程。
非核心线程满了，再触发拒绝任务。
详细说明：
1 当一个任务通过submit或者execute方法提交到线程池的时候，如果当前池中线程数（包括闲置线程）小于coolPoolSize，则创建一个线程执行该任务。
2 如果当前线程池中线程数已经达到coolPoolSize，则将任务放入等待队列。
3 如果任务不能入队，说明等待队列已满，若当前池中线程数小于maximumPoolSize，则创建一个临时线程（非核心线程）执行该任务。
4 如果当前池中线程数已经等于maximumPoolSize，此时无法执行该任务，根据拒绝执行策略处理。
注意：当池中线程数大于coolPoolSize，超过keepAliveTime时间的闲置线程会被回收掉。回收的是非核心线程，核心线程一般是不会回收的。如果设置allowCoreThreadTimeOut(true)，则核心线程在闲置keepAliveTime时间后也会被回收。
任务队列是一个阻塞队列，线程执行完任务后会去队列取任务来执行，如果队列为空，线程就会阻塞，直到取到任务。
1.6. java锁机制
在java中，解决同步问题，很多时候都会使用到synchronized和Lock，这两者都是在多线程并发时候常使用的锁机制。在JDK1.6后，对synchronized进行了很多优化，如偏向锁、轻量级锁等，synchronized的性能已经与Reentrantlock大致相同，除非要使用Reentrantlock的一些高级功能（实现公平锁、中断锁等），一般推荐使用synchronized关键字来实现加锁机制。
Synchronized 是Java 并发编程中很重要的关键字，另外一个很重要的是 volatile。Syncronized 一次只允许一个线程进入由他修饰的代码段，从而允许他们进行自我保护。进入由Synchronized 保护的代码区首先需要获取 Synchronized 这把锁，其他线程想要执行必须进行等待。Synchronized 锁住的代码区域执行完成后需要把锁归还，也就是释放锁，这样才能够让其他线程使用。
Lock 是 Java并发编程中很重要的一个接口，它要比 Synchronized 关键字更能直译"锁"的概念，Lock需要手动加锁和手动解锁，一般通过 lock.lock() 方法来进行加锁， 通过 lock.unlock() 方法进行解锁。与 Lock 关联密切的锁有 ReetrantLock 和 ReadWriteLock。
ReetrantLock 实现了Lock接口，它是一个可重入锁，内部定义了公平锁与非公平锁。
ReadWriteLock 一个用来获取读锁，一个用来获取写锁。也就是说将文件的读写操作分开，分成2个锁来分配给线程，从而使得多个线程可以同时进行读操作。ReentrantReadWirteLock实现了ReadWirteLock接口，并未实现Lock接口。
Synchronized 的使用
修饰一个方法：即一次只能有一个线程进入该方法，其他线程要想在此时调用该方法，只能排队等候。
实例方法：锁住的是该类的实例对象
静态方法：锁住的是该类的类对象。
public synchronized void goHOme(){
}
public static synchronized void goHOme(){
}
修饰代码块：表示只能有一个线程进入某个代码段
public void numDecrease(Object num){
synchronized (num){
number++;
}
}
修饰一个类：作用的对象是这个类的所有对象，只要是这个类型的class不管有几个对象都会起作用。
class Person {
public void method() {
//锁住的是该类的类对象，如果换成this或其他object,则锁住的是该类的实例对象
synchronized(Person.class) {
// todo
}
}
}
获取对象锁
synchronized(this|object) {}
修饰非静态方法
获取类锁
synchronized(类.class) {}
修饰静态方法
Lock 的使用
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
}
使用示例：
Lock lock = ...;
lock.lock();
try{
//处理任务
}catch(Exception ex){
}finally{
lock.unlock(); //释放锁
}
Lock lock = ...;
if(lock.tryLock()) {
try{
//处理任务
}catch(Exception ex){
}finally{
lock.unlock(); //释放锁
}
}else {
//如果不能获取锁，则直接做其他事情
}
public void method() throws InterruptedException {
lock.lockInterruptibly();
try {
//.....
}
finally {
lock.unlock();
}
}
一般来说，使用Lock必须在try{}catch{}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。
注意，当一个线程获取了锁之后，是不会被interrupt()方法中断的。单独调用interrupt()方法不能中断正在运行过程中的线程，只能中断阻塞过程中的线程。因此当通过lockInterruptibly()方法获取某个锁时，如果不能获取到，只有进行等待的情况下，是可以响应中断的。而用synchronized修饰的话，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。
synchronized和Lock的区别？
主要区别：
synchronized是Java中的关键字，是Java的内置实现；Lock是Java中的接口。
synchronized遇到异常会释放锁；Lock需要在发生异常的时候调用成员方法Lock#unlock()方法。
synchronized是不可以中断的，Lock可中断。
synchronized不能去尝试获得锁，没有获得锁就会被阻塞； Lock可以去尝试获得锁，如果未获得可以尝试处理其他逻辑。
synchronized多线程效率不如Lock，不过Java在1.6以后已经对synchronized进行大量的优化，所以性能上来讲，其实差不了多少。
死锁
所谓死锁是指两个或两个以上的线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
死锁触发的四大条件？
互斥锁
请求与保持
不可剥夺
循环的请求与等待
简单死锁代码示例：
public class DeadLock {
public static String obj1 = "obj1";
public static String obj2 = "obj2";
public static void main(String[] args){
Thread a = new Thread(new Lock1());
Thread b = new Thread(new Lock2());
a.start();
b.start();
}
}
class Lock1 implements Runnable{
@Override
public void run(){
try{
System.out.println("Lock1 running");
while(true){
synchronized(DeadLock.obj1){
System.out.println("Lock1 lock obj1");
Thread.sleep(3000);//获取obj1后先等一会儿，让Lock2有足够的时间锁住obj2
synchronized(DeadLock.obj2){
System.out.println("Lock1 lock obj2");
}
}
}
}catch(Exception e){
e.printStackTrace();
}
}
}
class Lock2 implements Runnable{
@Override
public void run(){
try{
System.out.println("Lock2 running");
while(true){
synchronized(DeadLock.obj2){
System.out.println("Lock2 lock obj2");
Thread.sleep(3000);
synchronized(DeadLock.obj1){
System.out.println("Lock2 lock obj1");
}
}
}
}catch(Exception e){
e.printStackTrace();
}
}
}
可以看到，Lock1获取obj1，Lock2获取obj2，但是它们都没有办法再获取另外一个obj，因为它们都在等待对方先释放锁，这时就是死锁。
1.7. Java中Volatile关键字（重要）
基本概念：Java 内存模型中的可见性、原子性和有序性。
原子性：（原子是世界上的最小单位，具有不可分割性）原子性就是指该操作是不可再分的。不论是多核还是单核，具有原子性的量，同一时刻只能有一个线程来对它进行操作。简而言之，在整个操作过程中不会被线程调度器中断的操作，都可认为是原子性。比如 a = 1；
非原子性：
也就是整个过程中会出现线程调度器中断操作的现象
类似"a ++"这样的操作不具有原子性，因为它可能要经过以下两个步骤：
（1）取出 a 的值
（2）计算 a+1
如果有两个线程t1，t2都在进行这样的操作。t1在第一步做完之后还没来得及加1操作就被线程调度器中断了，于是t2开始执行，t2执行完毕后t1开始执行第二步(此时t1中a的值可能还是旧值，不是一定的，只有线程t2中a的值没有及时更新到t1中才会出现)。这个时候就出现了错误，t2的操作相当于被忽略了
类似于a += 1这样的操作都不具有原子性。还有一种特殊情况，就是long跟double类型某些情况也不具有原子性
只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。
举例：请分析以下哪些操作是原子性操作：
x = 10; //语句1
y = x; //语句2
x++; //语句3
x = x + 1; //语句4
其实只有语句1是原子性操作，其他三个语句都不是原子性操作。
语句1是直接将数值10赋值给x，也就是说线程执行这个语句的会直接将数值10写入到工作内存中。
语句2实际上包含2个操作，它先要去读取x的值，再将x的值写入工作内存，虽然读取x的值以及将x的值写入工作内存 这2个操作都是原子性操作，但是合起来就不是原子性操作了。
同样的，x++和 x = x+1包括2个操作：读取x的值，进行加1操作，写入新的值。
如何保证原子性？
synchronized、Lock、cas原子类工具
由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。其次cas原子类工具。
共享变量：如果一个变量在多个线程的工作内存中都存在副本，那么这个变量就是这个几个线程的共享变量
可见性：一个线程对共享变量值的修改，能够及时的被其它线程看到。也就是一个线程对共享变量修改的结果，另一个线程马上就能看到修改的值。
如何保证可见性？
volatile、synchronized、Lock
要想实现变量的一定可见，可以使用volatile。另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。(其实还有final，但是它初始化后，值不可更改，所以一般不用它实现可见性)。
指令重排：CPU在执行代码时，其实并不一定会严格按照我们编写的顺序去执行，而是可能会考虑一些效率方面的原因，对那些先后顺序无关紧要的代码进行重新排序，这个操作就被称为指令重排。指令重排在单线程情况下没有什么影响，但是在多线程就不一定了。
有序性：程序执行的顺序按照代码先后的顺序执行。
如何保证有序性？
volatile、synchronized、Lock
volatile:
volatile原理：Java语言提供了一种稍弱的同步机制，即volatile变量，用来确保将变量的更新操作通知到其他线程。当把变量声明为volatile类型后，编译器与运行时都会注意到这个变量是共享的，因此不会将该变量上的操作与其他内存操作一起重排序。volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。
在访问volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此volatile变量是一种比sychronized关键字更轻量级的同步机制。
当对非 volatile 变量进行读写的时候，每个线程先从内存拷贝变量到CPU缓存中。如果计算机有多个CPU，每个线程可能在不同的CPU上被处理，这意味着每个线程可以拷贝到不同的CPU cache 中。
而声明变量是 volatile 的，JVM 保证了每次读变量都从内存中读，跳过 CPU cache 这一步。
当一个变量定义为 volatile 之后，将具备两种特性：
1.保证此变量对所有的线程的可见性。当一个线程修改了这个变量的值，volatile 保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主内存是不确定的，当其他线程去读取时，此时主内存中可能还是原来的旧值，因此无法保证可见性。
2.禁止指令重排序优化。有volatile修饰的变量，赋值后多执行了一个“load addl $0x0, (%esp)”操作，这个操作相当于一个内存屏障（指令重排序时不能把后面的指令重排序到内存屏障之前的位置），只有一个CPU访问内存时，并不需要内存屏障；（什么是指令重排序：是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理）。
volatile 性能：
volatile 的读性能消耗与普通变量几乎相同，但是写操作稍慢，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。
volatile为什么不能保证原子性？
简单的说，修改volatile变量分为四步：
1）读取volatile变量到local
2）修改变量值
3）local值写回
4）插入内存屏障，即lock指令，让其他线程可见
这样就很容易看出来，前三步都是不安全的，取值和写回之间，不能保证没有其他线程修改。原子性需要锁来保证。（或者可以理解为线程安全需要锁来保证）。这也就是为什么，volatile只用来保证变量可见性和有序性，但不保证原子性。
2 jvm
2.1. java内存模型
-
Jvm内存区域(运行时数据区)划分:
程序计数器：当前线程的字节码执行位置的指示器，线程私有。
Java虚拟机栈：描述的Java方法执行的内存模型，每个方法在执行的同时会创建一个栈帧，存储着局部变量、操作数栈、动态链接和方法出口等，线程私有。
本地方法栈：本地方法执行的内存模型，线程私有。
Java堆：所有对象实例分配的区域。
方法区：所有已经被虚拟机加载的类的信息、常量、静态变量和即时编辑器编译后的代码数据
详细说明：
程序计数器
程序计数器（Program Counter Register） 是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。
字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
由于 Java 虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）都只会执行一条线程中的指令。
因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
如果线程正在执行的是一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址。
如果线程正在执行的是一个 Native 方法，这个计数器值则为空（Undefined）。
此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
Java 虚拟机栈
Java 虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是 Java 方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧（Stack Frame） 用于存储局部变量表、操作数栈、动态链接、方法出口等消息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
局部变量表存放了编译器可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）和 returnAddress 类型（指向了一条字节码指令的地址）。
其中 64 位长度的 long 和 double 类型的数据会占用两个局部变量空间（Slot），其余的数据类型只占用一个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
在 Java 虚拟机规范中，对这个区域规定了两种异常状态：
如果线程请求的栈深度大于虚拟机所允许的的深度，将抛出 StackOverflowError 异常。
如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），如果扩展时无法申请到足够的内存，就会抛出 OutOfMemoryError 异常。
本地方法栈
本地方法栈（Native Method Stack） 与虚拟机栈所发挥的作用是非常相似的，它们之间的区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。
在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（例如：Sun HotSpot虚拟机）直接就把虚拟机栈和本地方法栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出 StackOverflowError 和 OutOfMemoryError 异常。
Java 堆
对于大多数应用来说，Java 堆（Java Heap） 是 Java 虚拟机所管理的的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。
Java堆是垃圾收集器管理的主要区域，从内存回收的角度来看，由于现在收集器基本采用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有 Eden 空间、From Survivor 空间、To Survivor 空间等。
从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。不过无论如何划分，都与存放内容无关，无论哪个区域，存储的仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。
方法区
方法区（Method Area）与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
运行时常量池（Runtime Constant Pool） 是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译器生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。
既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时就会抛出 OutOfMemoryError 异常。
扩展：String s1 = "abc"和String s2 = new String(“abc”)的区别，生成对象的情况
指向方法区："abc"是常量，所以它会在方法区中分配内存，如果方法区已经给"abc"分配过内存，则s1会直接指向这块内存区域。
指向Java堆：new String(“abc”)是重新生成了一个Java实例，它会在Java堆中分配一块内存。
2.1. GC机制(重要)
GC 是 garbage collection 的缩写, 垃圾回收的意思. 也可以是 Garbage Collector, 也就是垃圾回收器.
Java的内存分配与回收全部由JVM垃圾回收进程自动完成。
面试题：“你能不能谈谈，java GC”
1、哪些对象可以被回收。
2、何时回收这些对象。
3、采用什么样的方式回收。
问题1：哪些对象可以被回收？
对象存活判断（如何判断对象可回收/垃圾搜集）
判断一个对象可以回收通常采用的算法是引用计数算法和可达性分析算法。由于互相引用导致的计数不好判断，Java采用的可达性算法。
-
引用计数算法
每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。此方法简单，效率很高，但是主流的JVM并没有选用这种算法来判定可回收对象，因为它有一个致命的缺陷，那就是它无法解决对象之间相互循环引用的的问题，对于循环引用的对象它无法进行回收。例：public class Object { public Object instance; public static void main(String[] args) { // 1 Object objectA = new Object(); Object objectB = new Object(); // 2 objectA.instance = objectB; objectB.instance = objectA; // 3 objectA = null; objectB = null; }程序启动后，objectA和objectB两个对象被创建并在堆中分配内存，这两个对象都相互持有对方的引用，除此之外，这两个对象再无任何其他引用，实际上这两个对象已经不可能再被访问（引用被置空，无法访问），但是它们因为相互引用着对方，导致它们的引用计数器都不为0，于是引用计数算法无法通知GC收集器回收它们。
实际上，当第1步执行时，两个对象的引用计数器值都为1；当第2步执行时，两个对象的引用计数器都为2；当第3步执行时，二者都清为空值，引用计数器值都变为1。根据引用计数算法的思想，值不为0的对象被认为是存活的，不会被回收；而事实上这两个对象已经不可能再被访问了，应该被回收。
-
可达性分析算法（根搜索算法）
在主流的JVM实现中，都是通过可达性分析算法来判定对象是否存活的。可达性分析算法的基本思想是：通过一系列被称为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots对象没有任何引用链相连，就认为GC Roots到这个对象是不可达的，判定此对象为不可用对象，可以被回收。
在上图中，objectA、objectB、objectC是可达的，不会被回收；objectD、objectE虽然有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。
在Java中，可作为GC Roots的对象包括下面几种：
1、java虚拟机栈中引用的对象；
2、方法区中类静态属性引用的对象；
3、方法区中常量引用的对象；
4、本地方法栈中Native(JNI)方法引用的对象。
第一和第四种都是指的方法的本地变量表，第二种表达的意思比较清晰，第三种主要指的是声明为final的常量值。
问题3：采用什么样的方式回收
GC常用算法
可达性分析算法只是知道了哪些对象可以回收，不过垃圾收集显然还需要解决后两个问题，什么时候回收以及如何回收，在根搜索算法的基础上，现代虚拟机的实现当中，垃圾搜集的算法主要有三种，分别是标记-清除算法、复制算法、标记-整理算法，这三种算法都扩充了根搜索算法，不过它们理解起来还是非常好理解的。
标记 -清除算法
就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将依旧存活的对象标记一遍，最终再将堆中所有没被标记的对象全部清除掉，接下来便让程序恢复运行。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。
它的主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高(递归与全堆对象遍历)；另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，内存的布局自然会乱七八糟。空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
复制算法
“复制”（Copying）的收集算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，持续复制长生存期的对象则导致效率降低。
标记-整理算法
复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记/整理算法要低于复制算法。
分代搜集算法(重要)
GC 分代的基本假设：绝大部分对象的生命周期都非常短暂，存活时间短。
“分代搜集”算法，把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。
新生代GC（minor GC）：指发生在新生代的垃圾回收动作，因为Java对象大多都具备朝生夕灭的特点，所以minor GC发生得非常频繁，一般回收速度也比较块。
老年代GC（Major GC/Full GC）：指发生在老年代的GC，它的速度会比minor GC慢很多。
问题2：何时回收这些对象?
回收的时机
JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。因此GC按照回收的区域又分了两种类型，一种是普通GC（minor GC），一种是全局GC（major GC or Full GC），它们所针对的区域如下。普通GC（minor GC）：只针对新生代区域的GC。全局GC（major GC or Full GC）：针对年老代的GC，偶尔伴随对新生代的GC以及对永久代的GC。由于年老代与永久代相对来说GC效果不好，而且二者的内存使用增长速度也慢，因此一般情况下，需要经过好几次普通GC，才会触发一次全局GC。
内存模型与回收策略
Java 堆（Java Heap）是JVM所管理的内存中最大的一块，堆又是垃圾收集器管理的主要区域，Java 堆主要分为2个区域-新生代与老年代，其中年轻代又分 Eden 区和 Survivor 区，其中 Survivor 区又分 From 和 To 2个区。
Eden 区
大多数情况下，对象会在新生代 Eden 区中进行分配，当 Eden 区没有足够空间进行分配时，虚拟机会发起一次 Minor GC，Minor GC 相比 Major GC 更频繁，回收速度也更快。 通过 Minor GC 之后，Eden 会被清空，Eden 区中绝大部分对象会被回收，而那些无需回收的存活对象，将会进到 Survivor 的 From 区（若 From 区不够，则直接进入 Old 区）。
Survivor 区
Survivor 区相当于是 Eden 区和 Old 区的一个缓冲，类似于我们交通灯中的黄灯。Survivor 又分为2个区，一个是 From 区，一个是 To 区。每次执行 Minor GC，会将 Eden 区和 From 存活的对象放到 Survivor 的 To 区（如果 To 区不够，则直接进入 Old 区）。Survivor 的存在意义就是减少被送到老年代的对象，进而减少 Major GC 的发生。Survivor 的预筛选保证，只有经历16次 Minor GC 还能在新生代中存活的对象，才会被送到老年代。
Old 区
老年代占据着2/3的堆内存空间，只有在 Major GC 的时候才会进行清理，每次 GC 都会触发“Stop-The-World”。内存越大，STW 的时间也越长，所以内存也不仅仅是越大就越好。由于复制算法在对象存活率较高的老年代会进行很多次的复制操作，效率很低，所以老年代这里采用的是标记——整理算法。
java垃圾收集器：(共7种，着重了解CMS和G1)
CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。
从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为4个步骤，包括：
初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）
其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行。老年代收集器（新生代使用ParNew）
G1收集器
与CMS收集器相比G1收集器有以下特点：
1、空间整合，G1收集器采用标记整理算法，不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。
2、可预测停顿，这是G1的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时 Java（RTSJ）的垃圾收集器的特征了。
使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔阂了，它们都是一部分（可以不连续）Region 的集合。
G1的新生代收集跟 ParNew 类似，当新生代占用达到一定比例的时候，开始出发收集。和 CMS 类似，G1 收集器收集老年代对象会有短暂停顿。
2.3. 类加载过程
类加载的过程？
-
加载：将类的全限定名转化为二进制流，再将二进制流转化为方法区中的类型信息，从而生成一个Class对象。
-
验证：对类的验证，包括格式、字节码、属性等。
-
准备：为类变量分配内存并设置初始值。
-
解析：将常量池的符号引用转化为直接引用。
-
初始化：执行类中定义的Java程序代码，包括类变量的赋值动作和构造函数的赋值。
-
使用
-
卸载
只有加载、验证、准备、初始化和卸载的这个五个阶段的顺序是确定的。
类加载的机制，以及为什么要这样设计？
类加载的机制是双亲委派模型。大部分Java程序需要使用的类加载器包括：
启动类加载器：由C++语言实现，负责加载Java中的核心类。
扩展类加载器：负责加载Java扩展的核心类之外的类。
应用程序类加载器：负责加载用户类路径上指定的类库
双亲委派模型如下：
双亲委派模型要求出了顶层的启动类加载器之外，其他的类加载器都有自己的父加载器，通过组合实现。
双亲委派模型的工作流程：
当一个类加载的任务来临的时候，先交给父类加载器完成，父类加载器交给父父类加载器完成，知道传递给启动类加载器，如果完成不了的情况下，再依次往下传递类加载的任务。
这样设计的原因：
双亲委派模型能够保证Java程序的稳定运行，不同层次的类加载器具有不同优先级，所有的对象的父类Object，无论哪一个类加载器加载，最后都会交给启动类加载器，保证安全。
