java - 为什么JVM不支持强制类/类加载器卸载？

Question

免责声明:我知道如何在JVM中加载类以及如何以及何时卸载它们。问题不是关于当前的行为，而是JVM为什么不支持“强制”类/类加载器卸载？

它可能具有以下语义:当类加载器被“强制卸载”时，其加载的所有类都被标记为“已卸载”，这意味着将不创建新实例(将引发异常，如“ClassUnloadedException”)。然后，此类卸载类的所有实例也都标记为“卸载”，因此对它们的每次访问都将引发InstanceUnloadedException(就像NullPointerException一样)。

实现:我认为，这可以在垃圾回收期间完成。例如，压缩收集器无论如何都移动 Activity 对象，因此它可以检查当前对象的类是否已“卸载”，而不是移动对象，而是将对内存的受保护页的引用更改为引用(访问它将抛出上述InstanceUnloadedException)。这也将有效地使对象成为垃圾。或者可能在GC的“标记”阶段完成。无论如何，我认为这在技术上是可行的，并且在没有“卸载”发生时开销很小。

理由:这种“硬核”机制对于运行时会很有用，在该运行时中会发生大量动态代码重载，并且可以容忍特定应用程序或部分应用程序的故障，而整个JVM的故障是不可取的。例如，应用程序服务器和OSGi运行时。

以我的经验，由于未正确清理引用(在长寿命线程中填充的静态字段中的ThreadLocal等)，在10个案例中有9个案例的动态重新部署会导致PermGenSpace。同样，拥有明确的异常而不是难以调试的泄漏可以帮助完善代码，从而避免任何引用泄漏到不受控制的长期作用域中。

你怎么看？

Answer 1

此功能只会造成破坏和混乱。强迫类的卸载会带来很多问题，就像不推荐使用的Thread.stop()那样，除了那会变得更糟。

仅作比较，由于突然的线程中断，Thread.stop()倾向于使许多对象处于不一致的状态，并且该线程可以执行任何类型的代码。在实践中编码是不可能的，或者至少是巨大的努力。在那种情况下，编写正确的多用途代码被认为几乎是不可能的，甚至是完全不可能的。

在您的情况下，这种功能会有类似的不良副作用，但规模要差得多。代码可能会意外地在任何地方得到异常，因此在实践中很难或不可能防御性地对它进行编码或处理它。假设您有一个执行某些IO的try块，然后废弃了一个类。该代码将在意外的地方抛出ClassUnloadedException，从而可能使对象处于不一致的状态。如果您尝试针对代码进行防御，则由于另一个意外的ClassUnloadedException，负责该防御的代码也可能会失败。如果您有一个finally块试图关闭资源，并且在该块内抛出ClassUnloadedException，则无法关闭该资源。再说一次，处理起来非常困难，因为处理程序也可能会收到ClassUnloadedException。

顺便说一下，NullPointerException是完全可预测的。您获得了指向null的指针，并尝试取消引用。通常，这是编程错误，但是行为是完全可预测的。 ClassCastException，IllegalStateException，IllegalArgumentException和其他RuntimeException是(或至少应该)在可预测的条件下发生的。不是RuntimeException的异常有时可能会意外发生(例如IOException)，但是编译器会强制您处理或抛出它们。

另一方面，StackOverflowError，OutOfMemoryError，ExceptionIninitializerError和NoClassDefFoundError是不可预测的事情，可能会在代码中的任何地方发生，并且很少有事情可以处理或从中恢复。当某些程序遇到这种情况时，通常它们会变得不稳定。少数尝试处理它们的方法，会限制警告用户必须立即终止它，也许试图保存未保存的数据。您的ClassUnloadedException是一种典型的情况，它将是ClassUnloadedError。它会像ExceptionIninitializerError或NoClassDefFoundError一样表现出来，在99％的情况下，这意味着您的应用程序已完全损坏，但由于它没有快速故障的行为而变得更糟，因此它具有更大的随机性，并且不可预测的

从本质上讲，动态重新部署是JVM /容器中可能发生的最丑陋的黑客之一，因为它彻底改变了已经在上面运行的代码，这往往使您陷入非常不稳定的随机错误行为。但是它有其价值，因为它在调试方面有很大帮助。因此，针对容器实现的不稳定行为的防御措施是为正在运行的程序创建一组新的类，并与较旧的类共享内存。如果程序的新旧部分不直接通信(即仅通过兼容的序列化或完全不通信)，则可以。如果没有结构上的变化并且没有 Activity 的对象依赖于已更改的某些特定实现细节，通常您也很安全。如果您确实遵循这些规则，则不会显示ClassUnloadedError。但是，在某些情况下，您可能不遵循这些规则并且仍然很安全，例如，修复方法中的错误并更改其参数，并且不存在依赖于该错误的 Activity 对象(即，它们从未存在或全部消失)。 。

但是，如果您确实希望在访问较旧部分的对象时抛出ClassUnloadedError，则此行为表示该隔离规则之一已被破坏，然后关闭所有内容。因此，同时拥有该程序的新旧部分是没有意义的，完全重新部署它会更简单。

关于GC中的实现，它不起作用。死对象是死的，无论其类对象是否也死了。卸载类的 Activity 对象不能被垃圾回收，因为它们仍然可以被其他对象访问，无论每个方法的实现是否会魔术般地更改为总是抛出异常/错误的对象。在任何实现中，回溯对对象的引用将是一项非常昂贵的操作，而多线程处理则将更加糟糕，这可能会严重破坏完美存在的对象和类的性能。

此外，动态加载类并非用于生产用途，仅用于开发人员测试。因此，没有必要为此功能购买所有麻烦和复杂性。

最后，在实践中，您的想法创建的东西将类似于Thread.stop()的东西与类似于NoClassdefFoundError的东西结合在一起，但是比两者之和要强。就像皇后一样，主教和象棋是象棋的结合体，但是比两者之和要强。这是一个非常糟糕的主意。