当不再使用时将 null 分配给 ref 有什么好处吗？
我听说将引用分配给 null 显式将有助于 gc 收集它。
这是真的吗？
如果一个对象超出了作用域，它会很快被GC吗？
I heard that assign a reference to null explicit will help gc to collect it.
Is that true?
If an object is out of scope, will it get gc quickly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一般来说，这是不可能回答的。然而，如果一个引用即将超出范围，那么在它超出范围之前将其设置为 null 几乎肯定不会有任何效果。
另一方面，如果引用变量是长期存在的，那么当不再需要引用的对象时，将其设置为 null 可能会很有用。
That is impossible to answer in general. However, if a reference is about to go out of scope, setting it to
nulljust before it does will almost certainly achieve nothing.On the other hand, if the reference variable is long-lived, then setting it to
nullmay be useful if the referenced object is no longer needed.通常，JVM 会在需要时执行垃圾收集，因此分配对 null 的引用不会帮助它更快地发生。
Typically the JVM will do garbage collection when it needs to, so assigning a reference to null will not help it happen more quickly.
如果您有一个打算保留的数组或引用，则值得将其清空。
如果您有一个带有大对象的长方法，该方法不会立即超出范围，则引用一个大对象可能值得将其
null。然而在这种情况下，最好在不再需要该对象的地方分解该方法，这样它就会超出范围。If you have an array or reference which you intend to keep it can be worth
nulling it out.If you have a long method with a large object which will not go out of scope immediately, refers to a large object it could be worth
nulling it out. However in this situation, it is better the break up the method at the point where the object is no longer needed so it goes out of scope.如果这是唯一的引用，那么 GC 可以释放该对象正在使用的堆上的空间。但是，如果存在对同一对象的另一个引用，则将第一个引用设置为 null 将不会执行任何操作。第二个引用仍将使对象保持活动状态 - 因此 GC 不会释放空间。
If that is the only reference then the GC can free the space on the heap that the object was using. However, if there is another reference to the same object then setting the first reference to null will do nothing. The second reference will still keep the object alive - so the GC will not free the space.
一般来说，如果引用即将超出范围，您不需要显式将其清空，因为无论如何它很快就会消失。
我有意识地使用的唯一显式清空或删除引用是：
关闭与生命周期比该资源更长的对象关联的资源。例如： java.sql.Connection 实现通常有一个关联的物理连接（例如 Socket）：当 java.sql.Connection 关闭时，您可以清空此物理连接，因为您不再使用它，而实际的 java.sql.Connection 实现通常具有关联的物理连接（例如 Socket）。 sql.Connection 将（可能）仍由用户无限期地持有。 （我使用这个示例是因为我是 JDBC 驱动程序的开发人员，一般来说，这个示例不会发生在 Java 开发人员中，但存在类似的情况）
处理相对较大的“丢弃”列表或数组结构中的对象。例如：JavaMail库提供了获取消息的方法；它们返回一组消息。如果您按顺序处理消息（然后不再需要它们），则在处理后清空数组条目可以减少应用程序的内存占用（使用 IMAP，它可以“按需”从服务器加载信息并将其存储在消息中） ，由于处理而增加其大小）。
可能还有其他一些情况，我会显式地将引用设为 null，但这通常表示某些内容不可用，而不是出于对垃圾收集或内存使用的担忧。
然而，一如既往：不要只是因为您认为它会有所帮助而为 null：如果您知道它会有所帮助，则为 null（因此分析代码，测量内存使用情况等）。如果这是一次性爱好申请或大学作业：请不要打扰。
In general, if the reference is about to go out of scope, you don't need to explicitly null it as it will be gone soon any way.
The only explicit nulling or removing of references I consciously use are:
Closing a resource associated with an object that has a longer lifetime than that resource. For example: a java.sql.Connection implementation usually has an associated physical connection (eg a Socket): when the java.sql.Connection is closed you can null this physical connection as you are no longer using it, while the actual java.sql.Connection will (might) still be held by the user for an indefinite time. (I use this example as I am a developer of a JDBC driver, in general this example does not occur for a Java developer, but similar situations exist)
Processing relatively large 'throw-away' objects in a list or array structure. For example: the JavaMail library provides methods to get messages; these return an array of messages. If you process the messages sequentially (and then no longer need them), nulling the array-entry after processing could reduce the memory footprint of your application (with IMAP it can 'on demand' load information from the server and store it in the message, increasing its size due to processing).
There are probably some other cases I will explicitly null a reference, but that is usually to signify the unavailability of something not out of concern about garbage collection or memory usage.
However as always: don't just null because you think it could help: null if you know it will help (so profile the code, measure memory usage etc). And if it is a one off hobby application or university assignment: don't bother.