JDK8线程池BUG引发的思考

引言

某一天逛网上帖子的时候，忽然发现了上面这一篇文章，然而着实没有想到一篇文章能牵扯出这么多货色，这篇文章介绍的是因为应用了JDK的线程池引发的一个BUG，牵扯到了GC和办法内联的优化对于代码运行产生的影响，线程池BUG在JDK8中就曾经存在然而直到JDK11才被修复，这里在原文的根底上补充相干的知识点，算是给本人做一个笔记。

原文：一个JDK线程池BUG引发的GC机制思考

知识点总结：

这里先阐明一下这篇文章的相干知识点间接进行一个总结，如果读者对于相干内容非常相熟的话这里也不节约各位的工夫，能够间接敞开本文了（哈哈）

  1. jdk并发线程设计中存在的BUG，对于Executors.newSingleThreadExecutor 的实现细节上的问题探讨。
  2. finalize() 终结器的介绍，以及终结器对于GC的影响，这里用《effective Java》中的第八条总结了一波。
  3. JVM中的JIT内联办法优化可能会导致对象的生命周期可能并不能保持到一个栈帧出栈，这也导致了Executors.newSingleThreadExecutor中通过finalize()形式回收资源导致线程池提前回收的BUG。
  4. 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() 的确不应该），这里我也不客气也要来鞭尸一番，为了剖析这些内容咱们必须要理解源代码怎么写的。这里先给一下集体参考各种材料之后得出的论断：

  1. Executors.newSingleThreadExecutor();在Jdk1.8中存在较大的隐患，当线程调用执行实现的同时如果此时线程对象的this援用没有发挥作用的时候，此时JIT优化和办法内联会提前断定以后的对象已死，GC会立马将对象资源开释，导致偶发性的线程池调用失败抛出回绝拜访异样。
  2. 当呈现多线程切换的时候GC线程会把没有进的this援用的对象提前进行回收，通过办法内联的形式探知某个对象在办法内的“生命周期”，所以很有可能线程池还在工作。
  3. 当对象仍存在于作用域（stack frame）时，finalize也可能会被执行，实质上因为JIT优化以及办法中的对象生命周期并不是直到办法执行完结才会完结，而是有可能提前结束生命周期。
  4. 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%，然而一旦被老师发现，哼哼，问题不仅全副作废，你还要独自安顿到一个教室全副重考！所以舞弊是贫贱险中求呀。

当然这种激进优化一旦出问题并不是马上就放弃优化，这时候还有一个技术叫做“内联缓存”，内联缓存 大抵的工作原理如下：

  1. 未产生办法调用，内联缓存为空。
  2. 第一次调用，记录办法接受者的版本信息到缓存中，后续的每次调用如果承受的版本都是一样的，这时候会应用单态内联缓存，通过缓存的形式调用要比不内联的虚办法调用多一次类型判断。
  3. 然而如果版本信息不统一，一样要进化成超多态的内联缓存模式，开销相当于查找虚办法表的办法分派。

以上就是办法内联干的一些事件，既然理解了办法内联和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.FinalizableDelegatedExecutorServicepublic void execute(Runnable command) {    try {        e.execute(command);    } finally { reachabilityFence(this); }}
提醒：当然还有一种办法是在代码中手动执行一下敞开线程池，也能够躲避JIT优化带来的奇怪景象。

如何躲避？

如何解决下面的问题以及如何和JIT和办法内联反抗？以JDK9为界的两种办法（技巧），JDK官网给出这种解决办法也阐明了目前状况下不会对于这种JIT优化做兜底解决，意思就是说不能让编译优化器去配合你的代码工作，而是要让你的代码能够合乎预期行为，集体来看其实四个字：关我屁事。

  1. 在Java 9里只有加上一个reachabilityFence()调用就没事了
Reference.reachabilityFence(executor); // HERE
  1. JDK8以及之前的版本中则须要 手动调用的形式让对象不会因为线程切换this援用被GC误判为不可达：
executor.shutdown(); // HERE

其实通篇看下来发现最初如同有点理论技巧和实践的货色如同就这两个办法。NONONO，软件的畛域有一句话说的好，叫做知其然知其所以然，如果咱们认为的抉择去知其然那么很有可能沦为“代码工具人”而不是一个会认真思考的程序员。

上面咱们再开掘一下终结办法的应用和细节，这些教条在《effective Java》这本神书外面介绍了，所以咱们间接从书中的内容进行总结吧。

  1. 其实还有一种形式，就是应用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()不应该做什么？

  1. 防止做任何工夫紧迫的事件，比方敞开一个文件流，或者敞开数据库，因为这个办法的线程优先级队列非常低并且哪怕是显式调用也依赖于垃圾收集器的效率和是否执行，所以禁止用它做任何系统资源的操作。
  2. 防止应用终结办法来更新线程状态。（神总是看的很远）
  3. 不要依赖System.gc)和System.runFinalization)办法，这两个办法都不能促使终结办法提前执行，另一个甚至曾经被废除了10多年了。
  4. 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，即便终结办法能施展肯定作用，也很容易不正确的应用导致下面提到一些问题，有的问题甚至会导致对象被净化攻打，所以须要非常小心。上面来看一下终结办法有哪些用处：

  1. 终结的第一个用处，是作为资源开释的一个安全网，保障客户端在无奈正确操作的状况下仍然能够用一道安全网作为资源开释的兜底，然而须要思考这样应用的代价，上面咱们从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资源。

  1. 终结的另一个用处是本地办法对等体，本地对等体指的是一个本地对象（非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书籍里也有让读者会误会的知识点。

写在最初

又是一篇长文，新的一年里心愿能给读者带来更多更有品质的文章。