问题描述
假设我使用 BeanManager#getBeans(Type,Annotation...) 和 BeanManager#resolve(Set) 以及 BeanManager#getReference(Bean,Type,CreationalContext) 以编程方式获取 bean 的上下文引用。 （这是标准的东西。）
进一步假设有问题的 bean 在 @Singleton 范围内（它可以是除 @Dependent 之外的任何范围；我选择了 @Singleton 只是 (a) 使其具体化和(b) 将客户端代理从图片中取出以保持简单）。 （请注意，严格来说，我应该不知道什么范围适用于我正在使用的 bean，但我的问题可能与此直接相关。）
进一步假设有问题的 bean 在它“内部”有一个 @Dependent 范围的上下文引用。 （这有助于强调 bean 销毁与 CreationalContext#release() 的必要配对；见下文。）
进一步假设我得到的参考是第一个这样的参考。也就是说，我获取此引用是导致创建底层上下文实例单例的原因。到目前为止一切都很好，很简单。好极了;我有我的对象。
我会用这个上下文参考做任何我要做的事情。现在我刚刚创建了一些东西，不想泄漏内存，那么……我该怎么办？
- 我是否应该简单地尝试破坏引用下的现有上下文实例，也许使用
AlterableContext#destroy(Contextual)？但是我现在不需要知道有关范围的详细信息以及是否适合销毁任何现有实例吗？ （当然，如果我这样做，我最好也给CreationalContext#release()打电话。） - 我是否应该简单地释放用于构造的
CreationalContext（而不显式销毁单例实例）？但这会破坏单例的依赖引用。这似乎会导致状态不一致。 - 我应该什么都不做吗？在
@Singleton的情况下，这没有坏处，因为单例的持续时间与应用程序一样长，但是，现在我必须再次了解有关范围的详细信息。这是故意的吗？
正确的答案是真的，我需要了解很多关于特定底层范围的事情（如果用户提供，可能无法做到），并且需要定制我的销毁/根据作用域的语义释放动作？
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）