我正在尝试辨别（部分）CDI 和 DI 之间的区别。
关于@Inject，CDI(JSR-299) 仅带来了 DI (JSR-330) 的什么？
CDI @Injects（就像 DI）是真的吗，但是它注入的生命周期与某些上下文/范围相关联。如果在使用 @Inject 时某个对象存在于某个范围内，那么您将获得一个存在于其声明所在的上下文/范围内的实例。如果一个对象不存在，则会创建一个新的实例。
因此，当您想确保获得注入的对象的正确实例时。即@Inject MyObject myObj；将获得会话范围内的 myObject 实例（假设我已经对其进行了注释）
这对吗？
【问题讨论】：
标签： java dependency-injection cdi guice jboss-weld
免责声明：我在 Red Hat 工作，我是 CDI 联合规范负责人。所以我对 CDI 的了解可能比其他 DI 解决方案要好。说了这么多，我尽量给你一个客观的答案
是的，这是正确的
查看各自的 API：
可以看到，CDI 远比 JSR 330 丰富。AtInject 规范只定义了 1 个接口和 5 个注解，以确保声明和解析注入的通用方式。它没有提供有关如何管理组件的任何规则，也没有提供有关其生命周期的任何规则。 CDI（实现 JSR 330）是一个完整的依赖注入规范，其实现可以与 Guice 或 Spring Core 进行比较。
CDI 还添加了上下文的概念（事件、可移植扩展、装饰器、拦截器）。正如您所说，它允许您在自己的生命周期中自动管理一个组件（bean）。您可以在较短寿命的 bean 中注入较长寿命的 bean，反之亦然（即在 @ApplicationScoped bean 中注入 @RequestScoped bean）。 bean 管理器将始终为您提供有关活动上下文的正确 bean。
CDI 还有一个更新版本的 JSR 346 (CDI 1.1)，在 9 个月前随 Java EE 7 一起发布。它添加了一些关于 bean 生命周期控制的有趣内容。您可以在 JBoss Wildlfy 8 或 Oracle Glassfish 4 应用程序服务器中使用它（其他服务器仍在使用其 Java EE 7 版本）或获取 Weld 2.x 并从 servlet 侦听器或 Java SE 引导 CDI，如果您更喜欢自己进行集成。
目前我们正在开发 1.2 版并为 CDI 2.0 准备 JSR 提案。
要了解有关 CDI 的更多信息，我建议您阅读 Weld documentation（Weld 是 CDI 参考实现），它从用户的角度非常好地介绍了规范。
【讨论】：