相关疑难解决方法(0)

来自javadoc

只要线程处于活动状态且ThreadLocal实例可访问,每个线程都会保存对其线程局部变量副本的隐式引用; 在一个线程消失之后,它的所有线程局部实例副本都要进行垃圾收集(除非存在对这些副本的其他引用).

从那看起来,ThreadLocal变量引用的对象只有在线程死亡时才会被垃圾收集.但是如果ThreadLocal变量a不再被引用并且是垃圾收集的呢？a如果持有的线程a仍然存活,那么仅由变量引用的对象是否会被垃圾回收？

例如,以下类具有ThreadLocal变量:

public class Test {
    private static final ThreadLocal a = ...; // references object b
}

此类引用一些对象,此对象没有其他引用.然后在上下文取消部署期间,应用程序类加载器成为垃圾收集的主题,但线程来自线程池,因此它不会死亡.对象b是否会被垃圾收集？

我正试图在Java流API中形成一个关于懒惰评估应用的cocise和一致的理解.

这是我目前理解的内容:

• 元素仅在需要时被消耗,即流是惰性的,并且中间操作是惰性的,例如过滤器,仅在需要时才过滤.
• 中间操作可以融合在一起(如果它们是无状态的).
• 短路操作不需要处理整个流.

我想做的是将所有这些想法结合起来,确保我不会歪曲任何事情.我发现它很棘手,因为每当我阅读有关Java流的任何文献时,它会继续说它们是懒惰的或利用惰性评估,然后非常可互换地开始讨论优化,例如融合和短路.

那么我说对于以下内容是否正确？

• 融合是如何在流API中实现延迟评估 - 即消耗元素,并且尽可能将操作融合在一起.我认为如果不存在融合那么我们肯定会回到急切的评估,因为替代方案只是处理每个中间操作的所有元素,然后再转移到下一个中​​间操作？

• 没有融合或懒惰的评估,短路是可能的,但通过这两个原则的实施,在流的背景下是非常有帮助的吗？

我对此有任何进一步的见解和明确表示感谢.

我们都知道，用Java分配的每个对象都增加了以后的垃圾回收周期的权重，并且Optional<T>对象没有什么不同。我们经常使用这些对象来包装可为空的对象，这将导致代码更安全，但是要花多少钱呢？

是否有人知道可选对象添加了什么样的附加GC压力，而不是简单地返回null，以及这对高通量系统的性能有什么样的影响？