杭州seo整站优化,全国有多少家展馆设计公司,网站开发简介,四川航天中瑞建设工程有限公司网站垃圾收集算法,垃圾收集器何时以及何时不使用Java中的专家引用 弱引用#xff0c;软引用和幻像引用既危险又强大。 如果以错误的方式使用它们#xff0c;则会破坏JVM性能。 但是#xff0c;如果使用正确的方法#xff0c;它们可以大大提高性能和程序清晰度。 弱引用和软引用… 垃圾收集算法,垃圾收集器 何时以及何时不使用Java中的专家引用 弱引用软引用和幻像引用既危险又强大。 如果以错误的方式使用它们则会破坏JVM性能。 但是如果使用正确的方法它们可以大大提高性能和程序清晰度。 弱引用和软引用在这三种中更为明显。 实际上它们几乎是同一件事 这个想法很简单就是将它们用于访问对象但不会阻止垃圾回收器回收该对象 Object ynew Object();
// y is a hard reference to the object
// and so that object cannot be reclaimed.Obejct xWeakReferenceObject(y);
// now x is a weak reference to the object
// (not to y - as y is just a variable).
// The object still cannot be reclaimed
// because y is still a hard reference to it.ynull;
// now there is only a weak reference to
//the object, it is eligible for garbage collection.if(x.get()null){System.out.println(The object has gone away);
}else{System.out.println(The object is x.get().toString());
} 您发现故意的错误吗 这是一个容易错过的东西并且可能不会在单元测试中显示。 这正是让我说的问题 仅在绝对必要且可能甚至没有的情况下才使用弱/软引用。 当JVM承受内存压力时它可能会在弱引用中的get方法的第一次和第二次调用之间回收该对象。 当在null上调用toString方法时这将导致程序引发null指针异常。 该代码的正确形式为 Object xx.get();
// Now we have null xor a hard reference to
// the object
if(znull){System.out.println(The object has gone away);
}else{System.out.println(The object is z.toString());
}我们为什么要他们 我们还没有完全谈到为什么它们真的非常危险。 为此我们需要了解为什么我们可能需要它们以及为什么我们需要它们。 在两种常见的情况下弱引用和软引用似乎是个好主意我们将在稍后介绍软和弱引用之间的区别。 首先是某种形式的RAM缓存。 它是这样的 我们有一些数据例如客户详细信息存储在数据库中。 我们一直在寻找它这很慢。 我们可以做的是将这些数据缓存在RAM中。 但是最终RAM将填充名称和地址并且JVM抛出OutOfMemoryError。 解决方案是将名称和地址存储在只能弱访问的对象中。 像这样 ConcurrentHasMapString,WeakReferenceCustomerInfo cachenew ConcurrentHashMap();
...
CustomerInfo currentCustomercache.get(customerName);
if(currentCustomernull){currentCustomerreloadCachesEntry(customerName);
} 这种无害的小模式非常有能力使巨型的JVM崩溃。 该模式使用JVM的垃圾回收器来管理内存中的缓存。 垃圾收集器从未被设计为这样做。 该模式通过用难以到达的对象填充内存来滥用垃圾收集器这些对象使JVM耗尽了堆空间。 当JVM的内存不足时它必须遍历其堆中的所有引用弱引用软引用和其他引用并回收RAM。 这是昂贵的并且显示为处理成本。 在具有许多处理器核心的超大型JVM实例上情况甚至更糟因为垃圾收集器很可能最终不得不执行“停止世界”的完整循环从而将性能降低到单核级别 我并不是说内存缓存技术不是一个好主意。 哦不这是个好主意。 但是仅将其扔到垃圾收集器上并且不期望麻烦是一种非常糟糕的设计选择。 弱vs软 有什么区别 好吧真的有很多。 在某些JVM例如客户端托管JVM的客户端但可能随时更改上弱引用被标记为优先垃圾收集。 换句话说与其他内存相比垃圾回收器应更努力地从它们引用的对象图中回收内存并且不引用软或硬引用。 软引用对他们没有这个想法。 但是这只是某些JVM上的可选概念不能被依赖而且还是一个坏主意。 我建议始终使用软引用或弱引用并坚持使用它。 选择您喜欢的声音。 我更喜欢WeakReference这个名字所以倾向于使用它。 还有一个区别。 被软引用和弱引用而不是硬引用引用的对象可能会遇到这样的情况即仍然可以从弱引用的.get方法中获取而不能从软引用的.get方法中获取。 反之亦然反之亦然。 依赖于此行为的代码可能是错误的标题。 弱引用的良好用法 确实存在。 弱引用对跟踪其他地方正在使用的对象很有用。 一个示例来自Sonic Field音频处理程序包。 在此示例中文件中的“插槽”包含音频数据并与内存中的对象相关联。 该模型不使用弱引用来引用数据的内存中副本。 在内存对象中使用插槽。 弱引用用于允许文件管理系统重用插槽。 使用插槽的代码不需要也不应该与磁盘空间的管理有关。 文件管理器很关心这样做。 文件管理器对使用插槽的对象有较弱的引用。 当请求一个新的插槽时文件管理器将检查通过弱引用引用的所有现有插槽这些弱引用已被回收因此从get方法返回null。 如果找到这样的引用则可以重用该插槽。 自动通知回收 有时我们可能想知道何时回收了弱引用或软引用或其他类型的幻像。 这可以通过排队系统来完成。 我们可以使用参考队列来做到这一点 WeakReference(T referent, ReferenceQueue? super T q) 我们做这样的事情 ReferenceQueue junkQ new ReferenceQueue();
....
WeakReferenceFileSlot mySlotnew WeakReference(aSlot);
....
// In a different thread - make sure it is daemon!
WeakReferenceFileSlot isDead;
while(true){isDead junkQ.remove();// Take some action based on the fact it is dead// But - it might not be dead - see end of post :(
...
} 但是请记住当弱引用在junkQ上结束时对其调用.get将返回null。 如果您必须存储信息以允许您感兴趣的任何操作发生在其他地方例如ConcurrentHashMap其中引用是关键 那么什么是幻影引用 虚拟引用是一种当您需要它们时您确实需要它们。 但是从表面上看它们似乎毫无用处。 您会看到每当在幻像引用上调用.get时总会返回null。 永远不可能使用幻像引用来引用它所引用的对象。 好吧-这不是真的。 有时我们可以通过JNI来实现这一目标但我们绝对不应该这样做。 考虑一下您在与Java对象关联的JNI中分配本机内存的情况。 这是JDK的noi包中的DirectBuffers使用的模型。 这是我在大型商业项目中反复使用的东西。 那么我们如何回收本机内存呢 对于类似文件的系统可以说在关闭文件之前不会回收内存。 这将资源管理的责任放在程序员的肩膀上 这正是程序员对文件之类的期望。 但是对于重量较轻的对象我们的程序员不喜欢考虑资源管理-垃圾收集器可以为我们做这件事。 我们可以将代码放在终结器中终结器调用JNI代码来回收内存。 这是很糟糕的就像致命的一样因为JVM几乎可以保证它们将调用终结器。 所以不要那样做 但是幻象引用可以解救 首先我们需要理解“幻影可到达”只有当幻象引用无法通过其他任何类型的引用硬弱或软到达时它才会被排队。 在这一点上幻影参考可以入队。 如果对象具有终结器则它将被忽略或运行。 但它不会“将物体带回生活”。 幻影可到达对象对于JNI本机代码或任何其他代码来说是“安全的”可以根据资源回收资源。 因此带有幻像引用的代码如下所示 ReferenceQueueFileSlot junkQ new ReferenceQueue();
....
PhantomFileSlot mySlotnew Phantom(aSlot);
....
// In a different thread - make sure it is daemon!
PhantomFileSlot isDead;
while(true){isDeadjunkQ.remove();long handlelookUpHandle(isDead);cleanNativeMemory(handle);
} 在这种模式下我们保留了一个句柄本机代码可使用该句柄在Java中的结构可能是另一个哈希图中查找和回收资源。 当我们完全确定Java对象无法重生时-它是幻影可到达的即幽灵-我们可以安全地回收本机资源。如果您的代码使用sun.misc.unsafe进行了其他“顽皮的”事情对于有关使用此技术的完整示例请参见这篇文章 。 关于幻影引用的最后思考。 从技术上讲可以使用弱引用来实现与上述相同的模式。 但是这并不是弱引用的目的并且这种模式会滥用它们。 幻象引用绝对保证对象确实已死因此可以回收资源。 仅举一个例子从理论上讲可以将弱引用加入队列然后由其终结器将对象恢复原状因为终结队列的运行速度比弱参考队列慢。 这种幻影恐怖故事不可能在幻影引用中发生。 有一个小问题这是JVM设计的弱点。 也就是说JNI全局弱引用类型与幻像引用具有未定义的关系。 有人建议即使将对象排队为幻像引用也可以使用全局弱引用来获取对象。 这是对JVM的一种特定实现的怪癖永远不要使用。 参考 弱更弱最弱利用垃圾收集器 以及来自Java日历日历博客上我们JCG合作伙伴 Alexander Turner的专业参考 。 翻译自: https://www.javacodegeeks.com/2012/12/weak-weaker-weakest-harnessing-the-garbage-collector-with-specialist-references.html垃圾收集算法,垃圾收集器
