共计 13111 个字符，预计需要花费 33 分钟才能阅读完成。
JDK8 线程池 BUG 引发的思考
引言
某一天逛网上帖子的时候，忽然发现了上面这一篇文章，然而着实没有想到一篇文章能牵扯出这么多货色，这篇文章介绍的是因为应用了 JDK 的线程池引发的一个 BUG，牵扯到了 GC 和办法内联的优化对于代码运行产生的影响，线程池 BUG 在 JDK8 中就曾经存在然而直到 JDK11 才被修复，这里在原文的根底上补充相干的知识点，算是给本人做一个笔记。
原文：一个 JDK 线程池 BUG 引发的 GC 机制思考
知识点总结：
这里先阐明一下这篇文章的相干知识点间接进行一个总结，如果读者对于相干内容非常相熟的话这里也不节约各位的工夫，能够间接敞开本文了（哈哈）
- jdk 并发线程设计中存在的 BUG，对于 Executors.newSingleThreadExecutor 的实现细节上的问题探讨。
- finalize() 终结器的介绍，以及终结器对于 GC 的影响，这里用《effective Java》中的第八条总结了一波。
- JVM 中的 JIT 内联办法优化可能会导致对象的生命周期可能并不能保持到一个栈帧出栈，这也导致了
Executors.newSingleThreadExecutor中通过 finalize()形式回收资源导致线程池提前回收的 BUG。 - JDK 官方网站的对于
Executors.newSingleThreadExecutor().submit(runnable)办法会抛出异样的探讨（参考下方材料第四条），然而直到 JDK11 才进行修复。
参考资料
上面这些参考资料都是非常优质，花不多的工夫就能有很大的播种，特地是 R 大的答复，几乎就是挪动的百科全书，赞。
Java 中, 为什么一个对象的实例办法在执行实现之前其对象能够被 GC 回收?（必读）
Can java finalize an object when it is still in scope?
Executors.newSingleThreadExecutor().submit(runnable) throws RejectedExecutionException
JVM Anatomy Quark #8: Local Variable Reachability
Jdk 的并发线程设计中存在的 BUG
这里有点同情写 Executors.newSingleThreadExecutor(); 这个办法的老哥了，网上的文章根本都要拿他写的代码来重复鞭尸（当然 JDK 官网谬误应用 finalize() 的确不应该），这里我也不客气也要来鞭尸一番，为了剖析这些内容咱们必须要理解源代码怎么写的。这里先给一下集体参考各种材料之后得出的论断：
Executors.newSingleThreadExecutor();在 Jdk1.8 中存在较大的隐患，当线程调用执行实现的同时如果此时线程对象的 this 援用没有发挥作用的时候，此时 JIT 优化和办法内联会提前断定以后的对象已死，GC 会立马将对象资源开释，导致偶发性的线程池调用失败抛出回绝拜访异样。- 当呈现多线程切换的时候 GC 线程会把没有进的 this 援用的对象提前进行回收，通过办法内联的形式探知某个对象在办法内的“生命周期”，所以很有可能线程池还在工作。
- 当对象仍存在于作用域（stack frame）时，
finalize也可能会被执行，实质上因为 JIT 优化以及办法中的对象生命周期并不是直到办法执行完结才会完结，而是有可能提前结束生命周期。 Executors.newSingleThreadExecutor的实现里通过 finalize 来主动敞开线程池的做法是有 Bug 的，在通过优化后可能会导致线程池的提前 shutdown 从而导致异样。
上面咱们一步步来解释这个 BUG 的起源，以及相干的知识点，最初咱们再讲讲如何躲避这个问题。
环境
JDK 版本：代码异样是在 HotSpot java8 (1.8.0_221) 模仿状况中呈现的（实际上直到 jdk11 才被正式修复）。
问题介绍
上面咱们从原文间接介绍一下这个线程池的 BUG 带来的奇怪景象。
问题：线上偶发线程池的问题，线程池执行带有返回后果的工作，然而发现被拒绝执行。
ava.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@a5acd19 rejected from java.util.concurrent.ThreadPoolExecutor@30890a38[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] 起因剖析：线程池中的线程被提前回收，上面给出一段模仿线程池的操作代码，在模仿代码中尽管 futureTask 显然是在线程池外面，同时依照失常的了解思路线程池对象必定是在栈帧中存活的，然而实际上对象却在办法执行的周期内间接被 GC 线程给回收了，导致了“回绝拜访”的 BUG（也就是呈现了线程池关了，外部的工作却还在执行的状况）：
public class ThreadPoolTest {public static void main(String[] args) {final ThreadPoolTest threadPoolTest = new ThreadPoolTest();
// 创立 8 个线程
for (int i = 0; i < 8; i++) {new Thread(new Runnable() {
@Override
public void run() {while (true) {
// 获取一个工作
Future<String> future = threadPoolTest.submit();
try {String s = future.get();
} catch (InterruptedException e) {e.printStackTrace();
} catch (ExecutionException e) {e.printStackTrace();
} catch (Error e) {e.printStackTrace();
}
}
}
}).start();}
// 子线程不停 gc，模仿偶发的 gc
new Thread(new Runnable() {
@Override
public void run() {while (true) {System.gc();
}
}
}).start();}
/**
* 异步执行工作
* @return
*/
public Future<String> submit() {
// 关键点，通过 Executors.newSingleThreadExecutor 创立一个单线程的线程池
// PS：留神是单线程的线程池
ExecutorService executorService = Executors.newSingleThreadExecutor();
FutureTask<String> futureTask = new FutureTask(new Callable() {
@Override
public Object call() throws Exception {Thread.sleep(50);
return System.currentTimeMillis() + "";}
});
// 执行异步工作
executorService.execute(futureTask);
return futureTask;
}
}集体的运行状况和原文不太一样，有时候是刚跑起来间接抛出异样，有时候在执行几秒之后才报错，所以这一段代码在不同电脑上出现的成果是不太一样的，然而能够确定的是 JDK 的写法是存在 BUG 的。
JIT 优化
对于下面的代码，咱们要如何验证 JIT 编辑器提前结束对象生命周期？这里咱们接着引申一下，这里摘录了 Stackflow 中的一篇文章，来验证一下 JIT 优化的导致对象提前结束生命周期的一个了解案例。这篇文章的老哥提了一个很有意思的问题，原文问的是 Can java finalize an object when it is still in scope? 也就是当 对象仍然在栈帧外面对象会提前结束生命周期么？这里咱们挑答复中给的一个测试代码进行剖析。
public class FinalizeTest {
@Override
protected void finalize() {System.out.println(this + "was finalized!");
}
public static void main(String[] args) {FinalizeTest a = new FinalizeTest();
System.out.println("Created" + a);
for (int i = 0; i < 1_000_000_000; i++) {if (i % 1_000_000 == 0)
System.gc();}
// System.out.println(a + "was still alive.");
}/* 运行后果：不放开正文：Created FinalizeTest@c4437c4
FinalizeTest@c4437c4 was finalized!
放开正文：Created FinalizeTest@c4437c4
com.zxd.interview.cocurrent.FinalizeTest@c4437c4 was still alive.
*/
} 在下面这一段代码中，如果把最初一行正文，发现在进行 GC 的时候，尽管 A 这时候应该还是存在于 main 的栈帧中，能够看到如果不放开正文呈现了很奇怪的景象那就是对象 a 被提前终止生命周期了，这也就导致和前文一样的景象，对象在办法块内提前结束了本人的生命周期，或者换个角度说因为垃圾收集线程的切换，此时发现 a 曾经没有任何 this 援用被开释掉内存。当然如果咱们加上被正文这段代码的成果就比拟合乎预期了，对象 a 的生命周期被保住了直到整个程序运行实现，这里就引出了一个论断：当对象仍存在于作用域（stack frame）时，finalize也可能会被执行。
那么为什么会呈现下面的奇怪景象呢？在原文中探讨的是 toString() 办法的底层是否会缩短对象的生命周期，其实这是一种和 JIT 优化反抗的解决形式，应用打印语句将 a 的生命周期缩短到办法出栈，这样就不会呈现 for 循环执行到一半对象 a 却提前“死掉”的状况了。在 JIT 的优化中，下面的代码中的对象 A 被认为是不可达对象所以被回收，这种优化和咱们短暂的编程习惯可能会南辕北辙，作为编程人员来说咱们总是心愿对象的生命周期能保持到办法实现，然而实际上 JIT 和办法内联会尽可能的回收不可达的对象，上面咱们就来理解一下什么是办法内联。
内联优化
在论断中讲述了内联优化代码的状况，上面咱们来看一下《深刻了解 JVM 虚拟机》是如何介绍办法内联的，办法内联简略的了解就是咱们常说的毁灭办法的嵌套，尽量让代码“合并”到一个办法体中执行，这样做最直观的体现就是能够缩小栈帧的入栈出栈操作，咱们都晓得尽管程序计数器不会内存溢出，然而虚拟机栈的大小是无限的，并且在 JDK5 之后每一个线程具备的虚拟机栈大小默认为 1M，显然缩小入栈和出栈的次数是一种“千里之行; 始于足下”的优化形式，也是能直观并且显著的晋升效率的一种优化伎俩。
为了更好了解办法内联，这里咱们举一个案例，上面的办法是有可能进行办法内联的：
public int add(int a, int b , int c, int d){return add(a, b) + add(c, d);
}
public int add(int a, int b){return a + b;} 值得注意的是只有应用 invokespecial 指令调用的公有办法、实例结构器、父类办法和应用 invokestatic 指令调用的静态方法才会被办法内联，也就是说如果能够话咱们还是尽量把办法设置为private、 static、 final，特地是静态方法能够间接内联到一个代码块。除此之外大部分的实例办法都是无奈被内联的，因为他设计的是分派和多态的抉择，并且因为 java 是一门面向对象的语言，最根本的办法函数就是虚办法，所以对虚办法的内联是一个难题。
小贴士：
非虚办法：如果办法在编译期就确定了具体的调用版本，这个版本在运行时是不变的，这样的办法称为非虚办法。
虚办法：静态方法、公有办法、final 办法、实例结构器、父类办法都是非虚办法。
顺带一提是办法内联相对不是在代码中实现的，其实认真想想也是能够了解，如果在代码外面实现办法的合并那么原有的逻辑就乱套了，所以为了解决下面这一系列问题 Java 的虚拟机首先引入叫做 类型继承关系剖析 （class Hierarchy Analysis CHA）技术，集体了解这种优化形式为“ 贫贱险中求 ”，次要是剖析某个类的继承树以及重写或者重写办法的信息，如果发现是非虚的办法，间接内联就能够了，然而如果是虚办法，则对于以后的办法进行查看，如果查看到“可能”只有一个版本尼玛就能够假如这一段代码就是它最终实现的样子，这种办法也被叫做“ 守护内联”，当然因为 Java 动静连贯的个性还有代理等状况，所以这种守护内联的形式最终是要留下逃生门的，一旦这样的激进优化呈现失败或者异样，则须要马上切回到纯解析的模式进行工作。
吐槽：这种优化形式有点像考试舞弊，老师没有发现就能始终瞄始终抄，效率晋升 200%，然而一旦被老师发现，哼哼，问题不仅全副作废，你还要独自安顿到一个教室全副重考！所以舞弊是贫贱险中求呀。
当然这种激进优化一旦出问题并不是马上就放弃优化，这时候还有一个技术叫做“内联缓存”，内联缓存 大抵的工作原理如下：
- 未产生办法调用，内联缓存为空。
- 第一次调用，记录办法接受者的版本信息到缓存中，后续的每次调用如果承受的版本都是一样的，这时候会应用 单态内联缓存，通过缓存的形式调用要比不内联的虚办法调用多一次类型判断。
- 然而如果版本信息不统一，一样要进化成超 多态的内联缓存模式，开销相当于查找虚办法表的办法分派。
以上就是办法内联干的一些事件，既然理解了办法内联和 JIT 优化
简略剖析 newSingleThreadExecutor
尽管咱们通过一系列的伎俩排查发现了一个 GC 中暗藏的“破绽”，然而咱们能够发现这其实归根结底是 JDK 代码的 BUG 导致了这一系列奇怪的问题产生，上面咱们回过头来简略剖析一下这个 BUG，上面是 JDK 源代码：
/**
* 创立一个执行器，它应用单个工作线程操作无界队列，并在须要时应用提供的 ThreadFactory 创立一个新线程。与其余等效的 {@code newFixedThreadPool(1, threadFactory)} 不同，返回的执行程序保障不能重新配置以应用其余线程。*
* @param threadFactory 创立新工厂时应用的工厂
* 线程
*
* @return 新创建的单线程 Executor
* @throws NullPointerException 如果 threadFactory 为空
*/
public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>(),
threadFactory));
}这个办法的 JavaDoc 的形容如下（英语水平无限，间接把 API 文档拿来机翻了）：
创立一个执行器，它应用单个工作线程操作 无界队列，并在须要时应用提供的 ThreadFactory 创立一个新线程。与其等效的 {@code newFixedThreadPool(1, threadFactory)} 不同，返回的实例并不能保障给其余的线程应用，其实从名字也能够看出，这里就是新建一个单线程的线程池。
这里能够看到 FinalizableDelegatedExecutorService 这个类重写了 finalize 办法，并且实际上外部调用的是一个包装器对象的终结办法，这样也就是所有奇怪景象的“罪魁祸首”了：
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>()));
}
static class FinalizableDelegatedExecutorService
extends DelegatedExecutorService {FinalizableDelegatedExecutorService(ExecutorService executor) {super(executor);
}
// 重写了 finalize 办法
protected void finalize() {super.shutdown();
}
} 对于 finalize 的相干细节会在下文进行总结，这里稍安毋躁，在代码中能够看到 newSingleThreadExecutor 返回的是一个包装类而不是自身，所以它是通过调用包装类的的顶级接口的 super.shutdown(); 进行资源敞开的，同时 super.shutdown(); 的动作是在终结办法外面实现，其实能够看到代码自身的用意是好的，让线程池在不再应用的状况下保障随着 GC 会进行回收。然而其实只有略微理解 finalize 的同学就应该分明，抛开 JIT 和办法内联不谈这种写法的代码自身执行后果就是“不确定”的，因为 finalize 执行取决于垃圾收集器的实现，同时他也不肯定会调用（比方 main 线程刚执行实现就 exits 了），所以如果对象的生命周期和作用域管制不当就会在垃圾收集线程 GC 的时候呈现 this 援用失落提前回收问题（当然这里是多线程切换导致的 GC）。
此时咱们能够回顾一下之前原文中的测试代码，线程池在开启之后他看上去如同就没有在干活了（实际上外部有线程对象在执行工作），显然这里想要利用 finalize()作为“安全网”进行线程资源的回收的伎俩有失偏颇，最初这个对于 JDK 的线程池 BUG 是在 JDK11 修复的，他的解决代码如下：
JUC Executors.FinalizableDelegatedExecutorService
public void execute(Runnable command) {
try {e.execute(command);
} finally {reachabilityFence(this); }
}提醒：当然还有一种办法是在代码中手动执行一下敞开线程池，也能够躲避 JIT 优化带来的奇怪景象。
如何躲避？
如何解决下面的问题以及如何和 JIT 和办法内联反抗？以 JDK9 为界的两种办法（技巧），JDK 官网给出这种解决办法也阐明了目前状况下不会对于这种 JIT 优化做兜底解决，意思就是说不能让编译优化器去配合你的代码工作，而是要让你的代码能够合乎预期行为，集体来看其实四个字：关我屁事。
- 在 Java 9 里只有加上一个 reachabilityFence()调用就没事了
Reference.reachabilityFence(executor); // HERE- JDK8 以及之前的版本中则须要 手动调用 的形式让对象不会因为线程切换 this 援用被 GC 误判为不可达：
executor.shutdown(); // HERE 其实通篇看下来发现最初如同有点理论技巧和实践的货色如同就这两个办法。NONONO，软件的畛域有一句话说的好，叫做知其然知其所以然，如果咱们认为的抉择去知其然那么很有可能沦为“代码工具人”而不是一个会认真思考的程序员。
上面咱们再开掘一下终结办法的应用和细节，这些教条在《effective Java》这本神书外面介绍了，所以咱们间接从书中的内容进行总结吧。
- 其实还有一种形式，就是应用
try - final的形式进行解决，在学习根底的时候咱们都晓得 final 语句是必然会执行的，也能够保障 this 援用直到 final 执行实现才被开释援用。
补充：阿里巴巴开发倡议
其实阿里巴巴的手册很早之前就禁止应用 Executors 去创立线程，当初看来这里其实暗藏着另一个陷阱，那就是 SingleThreadPool 重写了 finalize 办法可能因为 JIT 优化和办法内联而进坑外面，也算是不应用的一个理由吧。
上面是手册的介绍，这里间接贴过来了：
线程池 不容许应用 Executors 去创立，而是通过 ThreadPoolExecutor 的形式，这样的解决形式让写的同学更加明确线程池的运行规定，躲避资源耗尽的危险。
1）FixedThreadPool 和 SingleThreadPool : 容许的 申请队列长度为 Integer.MAX_VALUE，可能会沉积大量的申请，从而导致 OOM。
2）CachedThreadPool 和 ScheduledThreadPool : 容许的创立线程数量为 Integer.MAX_VALUE，可能会创立大量的线程，从而导致 OOM
（感兴趣的同学能够翻翻手册的“并发”局部，在靠前的几条就有介绍（阐明翻车的人还挺多？））
finalize
咱们联合《effective Java》中的第八条理解一下终结办法是什么，这里会介绍终结办法的各种应用办法和隐患，以及如果重写 finalize()在 GC 中会产生什么变动。
什么是 finalize？
- finalizer 在 JAVA 中意味着 JVM 进行 GC 之前执行对象终结生命的非凡办法。
- 在 Java 中，finalizer 被称为 finalize()) 办法。
- Java 中的
finalize()在垃圾回收确定不再有对对象的援用时执行。 finalize()并不是保障被调用的，所以不会呈现因为内存清理的操作导致 OOM。- 对于 C ++ 程序员来说，finalizer 不能被认为是析构函数，在 C ++ 中析构函数用于回收一个对象占用资源，是结构器必须的对应产物。
什么对象会被 finalize?（重点）
这里也是从 R 大的答复里总结过去的，真堪称听君一席话，胜读十年书。对于一个对象来说咱们须要辨别重写 finalize()和不重写 finalize()，如果 不重写 finalize()，其实对象的生命周期只有一次，也就是一旦 GC 对象是不会通过 finalize() 间接进行回收的，这和《深刻了解 JVM 虚拟机》中是有出入的（书中介绍的是对象经验 GC 至多须要两次考验，其实不重写 finalize()一次考验就挂了），然而如果重写了 finalize()，那么此时对象从失去强援用到真正被 GC 回收会经验两次 GC，重写过 finalize()的办法的对象的时候虚构机会对这个对象做非凡解决，把他放入一个 finalize() 的低优先级非凡队列，在 GC 的时候如果通过队列判断以后对象是一个不可达对象，如果是则会进行回收的操作。
finalize()不应该做什么？
- 防止做任何工夫紧迫的事件，比方敞开一个文件流，或者敞开数据库，因为这个办法的线程优先级队列非常低并且哪怕是显式调用也依赖于垃圾收集器的效率和是否执行，所以禁止用它做任何系统资源的操作。
- 防止应用终结办法来更新线程状态。（神总是看的很远）
- 不要依赖 System.gc) 和System.runFinalization)办法，这两个办法都不能促使终结办法提前执行，另一个甚至曾经被废除了 10 多年了。
- System.runFinalizersOnExit)和 Runtime.runFinalizersOnExit) 已被弃用。
finalize()潜在问题
对象 broken 问题
finalizers 的一个潜在重大问题在终结的时候如果抛出未被捕捉的异样，该对象的总结过程也会一并终止，并且此时对象会进入 broken 状态，如果此时这个对象被另一个对象应用，会呈现不确定的行为，失常状况下未被捕捉的异样根本会被 Jvm 捕捉最终强制终止线程，并且打印堆栈，然而如果异样在终结办法中则齐全报不出错来。革除办法尽管没有问题，然而革除办法有一个和 finalize 一样的性能问题。
性能问题
另一个问题是终结办法和革除办法一样存在很重大的性能问题，通过测试发现应用 jdk7 的 AutoCLoseable 接口和 try-catch-resources，比减少一个终结办法要快上 50 倍，尽管应用革除办法革除类的实例比终结办法要快一些，然而也是五十步笑百步的区别。
革除办法：
平安问题
最初终结办法有重大的平安问题，那就是终结办法攻打，如果一个异样在构造方法或它的序列化等价办法 -readObject()和 readResolve()办法抛出，尽管构造方法能够失常抛出异样并且提前结束线程的生命周期，然而对于终结办法并不是如此，终结办法能够在动态字段中记录对象的援用，避免被垃圾回收，同时一旦被记录异样，那么就能够调用任何本来不应该容许呈现的办法，所以 从结构器抛出异样尽管足以阻止对象存活，然而对于终结办法来说，这一点无奈实现。
为了解决这个问题，最终倡议的办法是重写一个空的并且为 final 的终结办法。同时如果想要让相似文件或者数据库的资源主动回收，最好的形式是实现 jdk7 之后提供的 autoClosed 接口，而后应用 try-catch-resources 主动敞开资源，即便遇到异样也会主动回收对象。和终结的破绽不同的是，应用 autoclosed 必须记录本人是否敞开，同时如果资源是在被回收之后调用的，则必须要查看这个标记，最终抛出 java.lang.IllegalStateException 异样。
应用 finalize 须要留神什么？
如果须要重写 finalize 须要留神上面的事项。
- 如果子类重写了终结办法，则必须要应用 superd 调用父类的终结办法，因为终结链不会主动执行。
- 如果用户遗记调用显式终止办法，终结器应记录正告。
- 对于本地对等点（一般对象通过本地办法委托给的本地对象，而垃圾收集器不晓得也无奈回收它）。
finalize 的正确用法
finalize 当然并不是齐全一无是处，因为在 java 中的确有不少常见的类进行应用，所以有必要介绍一下他的正确办法，当然还是倡议读者不要去触碰应用终结办法和防止应用革除对象 Cleaner，即便终结办法能施展肯定作用，也很容易不正确的应用导致下面提到一些问题，有的问题甚至会导致对象被净化攻打，所以须要非常小心。上面来看一下终结办法有哪些用处：
- 终结的第一个用处，是作为资源开释的一个安全网，保障客户端在无奈正确操作的状况下仍然能够用一道安全网作为资源开释的兜底，然而须要思考这样应用的代价，上面咱们从 fileInputStream 类的终结办法看一下它是如何平安应用的。从上面的代码能够看到，如果以后被开释的资源不为 Null 并且不是 System#in 控制流的时候就开释资源。
/**
确保在不再援用此文件输出流时调用该文件输出流的 close 办法。*/
protected void finalize() throws IOException {if ((fd != null) && (fd != FileDescriptor.in)) {
/* 如果 fd 是共享的，则 FileDescriptor 中的援用
* 将确保仅在以下状况下调用终结器
* 这样做是平安的。所有应用 fd 的援用都有
* 变得无法访问。咱们能够调用 close()
*/
close();}
} 从集体的的角度来看，这样的应用形式一方面是因为 JDK 晚期版本没有 try-catch-resource 导致某些异常情况下 IO 流无奈失常敞开所以应用这样的写法，另一方面是思考极其状况下仍然须要开释资源的状况，所以重写 finalize 作为一张安全网开释 IO 资源。
- 终结的另一个用处是本地办法对等体，本地对等体指的是一个本地对象（非 JAVA 对象），一般办法通过本地办法委托给一个本地对象，因为本地办法是不受 JVM 管制所以当 JAVA 对象被回收的时候它并不会回收，所以如果本地办法没有要害资源并且性能足够被承受，就能够应用终结或者革除办法来回收这些对象。
本地对等体的解释和理论应用（机翻）：
一个 AWT 组件通常是一个蕴含了对等体接口类型援用的组件类。这个援用指向本地对等体实现。以
java.awt.Label为例，它的对等体接口是 LabelPeer。LabelPeer 是平台无关的。在不同平台上，AWT 提供不同的对等体类来实现 LabelPeer。在 Windows 上，对等体类是 WlabelPeer，它调用 JNI 来实现 label 的性能。这些 JNI 办法用 C 或 C ++ 编写。它们关联一个本地的 label，真正的行为都在这里产生。作为整体，AWT 组件由 AWT 组件类和 AWT 对等体提供了一个全局专用的 API 给应用程序应用。一个组件类和它的对等体接口是平台无关的。底层的对等体类和 JNI 代码是平台相干的。上面是原文，英语水平还不错的能够尝试浏览一下：
(An AWT component is usually a component class which holds a reference with a peer interface type. This reference points to a native peer implementation.
Take java.awt.Label for example, its peer interface is LabelPeer.
LabelPeer is platform independent. On every platform, AWT provides different peer class which implements LabelPeer. On Windows, the peer class is WlabelPeer, which implement label functionalities by JNI calls.
These JNI methods are coded in C or C++. They do the actual work, interacting with a native label.
Let’s look at the figure.
You can see that AWT components provide a universal public API to the application by AWT component class and AWT peers. A component class and its peer interface are identical across platform. Those underlying peer classes and JNI codes are different. )
值得一提的是，在《effective Java》这本书的最初局部，给到了一个正确应用的案例，然而在最初通过一个客户端的谬误应用发现仍然会导致各种奇怪的景象，这里也阐明了 finalize 这个办法的不确定性，同时一旦重写了这个办法就要考量对于程序性能的影响，因为它的调用与否取决于 GC 的实现。
finalize()总结
总之不要应用终结器，除非将其用作 安全网 或终止非关键本机资源。在极少数状况下，如果您的确应用终结器，请记住调用 super.finalize（）。最初如果应用终结器作为安全网，请记住从终结器中记录有效应用状况。
最初再提一句：JDK9 曾经将 finalize 废除，然而为了兼容思考仍然还有类在应用。
总结
在这篇文章中笔者依据一篇文章总结了一些集体学习到的 GC 的细节常识，同时依据文章提到的知识点去回顾了对于办法内联优化以及终结办法的细节，从这篇文章看出一个简略的 BUG 就能牵扯出如此多的知识点，最初甚至波及到了优化器和解释器的设计层面，当然如果读者不是从事 JVM 畛域的钻研或者波及的人，其实只有简略晓得优化器会干出一些失常逻辑下“不能了解”的事件即可，比方 this 局部变量表中的对象如果 this 援用没有被应用很容易被 JIT 给内联优化掉。
最初，心愿这篇文章能够切实的帮到你，学习任何内容肯定不要简略的复制粘贴造成惯性和固定思维，而是要宽泛浏览和汇总思考一直的纠错和回顾，最初造成的观点才有可能的是正确的，毕竟就连周大神的 JVM 书籍里也有让读者会误会的知识点。
写在最初
又是一篇长文，新的一年里心愿能给读者带来更多更有品质的文章。