可以因任何原因在运行时从上下文或垃圾收集中删除QUKUS/CDI Application ationScoped bean吗？
我的理解是，这些bean是简单的java对象，但是一旦它们在构建时被删除并（懒惰地）初始化后幸存下来，它们就会无限期地保存在上下文中，即使它们长时间处于空闲状态，也不应该具有GC功能。
但是在运行了2.0 CDI规范和bean生命周期/CDI相关的Quarkus文档后，我无法确认它。
有没有可能发生这种情况的具体情况？
共有1个答案
所以在理论上，你可以做AlterableContext#销毁（context）
例如，在quarkus中，您可以执行Arc。容器（）。实例（MyApplicationScopedFoo.class）。销毁（）。这将调用@PreDestroy回调（如果存在），@PreDestroy拦截器（如果绑定），并从应用程序上下文中删除MyApplicationScopedFoo实例。
-
在生产环境中运行的当前基于BPM的应用程序（在JBOSS中作为4.2.3部署）中，注意到了一些性能问题，这是因为在峰值负载期间运行的GC暂停周期较长。通过进一步分析，我发现运行JVM实例的jstat实用程序有以下输出。 /usr/jdk1.6.0-x64/bin/jstat-gccapacity 5583 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC
-
问题内容： 我有一段代码可以在内存中加载很大的图像。所以打电话似乎是合理的事情 在加载图像之前。据我所知，它毫无问题。 昨天，我决定使用一个名为FindBugs的非常有用的软件来扫描您的代码并报告可能导致错误或通常不建议使用的策略的问题。问题是我提到的这段代码得到了报告。描述是这样的： …强迫垃圾收集；除了基准测试代码外，都非常可疑 并继续阐述： 代码显式调用垃圾回收。除了基准测试中的特定用途外，
-
问题内容： 简短形式：CMS垃圾收集器似乎无法收集数量不断增加的垃圾；最终，我们的JVM填满，应用程序变得无响应。通过外部工具（JConsole或）强制GC 清理一次。 更新：该问题似乎与JConsole的JTop插件有关。如果我们不运行JConsole，或者在没有JTop插件的情况下运行它，则该行为消失。 （技术说明：我们正在Linux 2.6.9机器上运行32位Sun JDK 1.6.0_07
-
Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。 注意：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。 Owner 和 Dependent 一些 Kubernetes 对象是其它一些的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner 的对象被称为是 Owner
-
我有一个Springboot Maven项目，它使用@JmsListener从队列中读取消息。 如果没有事件进来，堆内存会慢慢增加。当消息传来时，堆内存会快速增加。但是堆内存永远不会下降（查看下图）。 如果我添加系统。gc（）在receiver方法的末尾，垃圾收集器正在按预期完成其工作。但这绝对不是好的做法。 如何确保gc在适当的时间运行。任何帮助都将不胜感激！ 堆内存使用率 接收方法
-
问题内容： 我对可以控制CMS收集器启动时间的两个参数感到困惑： （默认为70％） （默认情况下超过90％） 这些参数的确切含义是什么？收集器什么时候开始（标记阶段）并收集（清扫阶段）？ 问题答案： 决定何时启动CMS（为了使此选项生效，您还必须设置）。是确定世代空间大小的选项。 参见例如… http://java.sun.com/docs/hotspot/gc1.4.2/faq.html 通常无