安卓在C和系统中退出（0）的实践。在Java中退出（0）

Question

在C中使用exit(0)不是一个好的实践，如果有替代方法的话，因为它不会释放资源。但是要在Java中使用System.exit(0)，这里的情况如何？在这种情况下，可以信任垃圾收集器吗

C语言：

 exit(0);

爪哇：

 System.exit(0)

Answer 1

这样想吧。在C语言中，您将源代码构建成一个二进制文件，该文件将根据逻辑编程规则和操作系统设置的规则自行执行。不过，操作系统不会为您管理内存。它处理事件，并向硬件发送信息，告诉它如何运行，不多不少。在java中，所有代码都被编译成java自己的字节码。在执行时，它实际上在任何时候都不会与操作系统通信。设计用来运行字节码的虚拟机就是用来说话的。当你呼叫系统时。退出（0），你告诉虚拟机你正在运行的应用程序即将停止，从那里机器处理它自己的内存，这恰好包括你没有通过垃圾收集器删除的任何内容，但只有当虚拟机也退出时。希望有帮助

Answer 2

But to use System.exit(0) in java - how is it here? Could one trust the garbage-collector in this context?

在Java中调用System.exit时，垃圾收集器通常不会运行¹。然而，在我听说过的任何JVM中，都有其他东西可以回收分配的所有对象。（通常在操作系统级别进行处理。）

只有在JVM终止之前依赖对象终结器来完成一些重要的事情时，GC才不会运行这一事实才有意义

假设，如果Java应用程序使用JNI（etc）调用本机方法，那么这些方法可能会访问可能有问题的系统资源。然而：

1. 一般来说，操作系统会处理这些事情。至少对于现代版本的Linux和UNIX，AFAIK是这样

2. 垃圾收集器无论如何都不知道这些资源。如果操作系统不能回收它们，那么Java垃圾回收器也帮不了忙

如果确实需要清理Java程序（通过本机代码）获取的此类资源，那么最好的方法是在本机代码方法中实现清理，并使用“关机挂钩”来运行它们。如果调用System.exit，将运行关闭挂钩

---

^{1-如果您之前调用过^{，则会在JVM出口上执行垃圾收集。然而，这是一种被弃用的方法。甲骨文网站这样解释：}

^{Q: Why is Runtime.runFinalizersOnExit deprecated?}

^{A: Because it is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock. While this problem could be prevented if the class whose objects are being finalized were coded to "defend against" this call, most programmers do not defend against it. They assume that an object is dead at the time that its finalizer is called.}

^{Further, the call is not "thread-safe" in the sense that it sets a VM-global flag. This forces every class with a finalizer to defend against the finalization of live objects!}

简而言之，这是一种危险的方法，它不会直接处理OP担心的资源类型