Update 07. 消除过期的对象引用.md

This commit is contained in:
Joe 2019-09-19 18:03:54 +08:00 committed by GitHub
parent d0f607b51c
commit 91ee5f09ba
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -37,9 +37,9 @@ public class Stack {
}
}
```
  这个程序没有什么明显的错误(但是对于泛型版本,请参阅条目 29。 你可以对它进行详尽的测试,它都会成功地通过每一项测试,但有一个潜在的问题。 笼统地说,程序有一个“内存泄漏”,由于垃圾回收器的活动的增加,或内存占用的增加,静默地表现为性能下降。 在极端的情况下这样的内存泄漏可能会导致磁盘分页disk paging甚至导致内存溢出OutOfMemoryError的失败但是这样的故障相对较少。
  这个程序没有什么明显的错误(但是对于泛型版本,请参阅条目 29。 你可以对它进行详尽的测试,它都会成功地通过每一项测试,但有一个潜在的问题。 笼统地说,程序有一个「内存泄漏」,由于垃圾回收器的活动的增加,或内存占用的增加,静默地表现为性能下降。 在极端的情况下这样的内存泄漏可能会导致磁盘分页disk paging甚至导致内存溢出OutOfMemoryError的失败但是这样的故障相对较少。
  那么哪里发生了内存泄漏? 如果一个栈增长后收缩,那么从栈弹出的对象不会被垃圾收集,即使使用栈的程序不再引用这些对象。 这是因为栈维护对这些对象的过期引用obsolete references。 过期引用简单来说就是永远不会解除的引用。 在这种情况下,元素数组“活动部分active portion之外的任何引用都是过期的。 活动部分是由索引下标小于 size 的元素组成。
  那么哪里发生了内存泄漏? 如果一个栈增长后收缩,那么从栈弹出的对象不会被垃圾收集,即使使用栈的程序不再引用这些对象。 这是因为栈维护对这些对象的过期引用obsolete references。 过期引用简单来说就是永远不会解除的引用。 在这种情况下,元素数组「活动部分active portion之外的任何引用都是过期的。 活动部分是由索引下标小于 size 的元素组成。
  垃圾收集语言中的内存泄漏(更适当地称为无意的对象保留 unintentional object retentions是隐蔽的。 如果无意中保留了对象引用,那么不仅这个对象排除在垃圾回收之外,而且该对象引用的任何对象也是如此。 即使只有少数对象引用被无意地保留下来,也可以阻止垃圾回收机制对许多对象的回收,这对性能产生很大的影响。
@ -68,7 +68,7 @@ public Object pop() {
  第三个常见的内存泄漏来源是监听器和其他回调。如果你实现了一个 API其客户端注册回调但是没有显式地撤销注册回调除非采取一些操作否则它们将会累积。确保回调是垃圾收集的一种方法是只存储弱引用weak references例如仅将它们保存在 `WeakHashMap` 的键key中。
  因为内存泄漏通常不会表现为明显的故障,所以它们可能会在系统中保持多年。 通常仅在仔细的代码检查或借助堆分析器( heap profiler的调试工具才会被发现。 因此,学习如何预见这些问题,并防止这些问题发生,是非常值得的。
  因为内存泄漏通常不会表现为明显的故障,所以它们可能会在系统中保持多年。 通常仅在仔细的代码检查或借助堆分析器heap profiler的调试工具才会被发现。 因此,学习如何预见这些问题,并防止这些问题发生,是非常值得的。