创建10s / 100s的Guice注射器被认为是不好的做法/设计吗？

Question

考虑一个假设的应用程序：

• 需要创建数十个甚至数百个小组对象
  • （A组：A类实例，D类实例，M类实例。属性P'）
  • （B组：B类实例，D类实例）
  • （C组：B类实例，D类实例，F类实例。属性P''）
• 这些对象中的每一个都是由自己的Provider创建的，该Provider使用MapBinder或MultiBinder（典型的“插件”用例）向父/根Injector注册
• 要创建每个组，将创建一个新的子Injector，它使用来自根的提供者和本子注入的一些其他提供者 - 类似于配置/属性绑定
• 这个紧密的一组对象一起创建，以执行一些任务，然后一起丢弃 - 几个小时后
• 该组有一些独特的参数
  • 意思是，在组内创建的每个对象都具有不同的配置属性
  • 它们与另一组中该类的另一个实例不同

问题： 假设由于某种原因，使用像Factory，Builder，Creator等工厂设计模式的运行无法实现上述问题：

• 上述方法有什么问题吗？
  • 表演，记忆足迹
  • 可读性（使用普通旧Java new）
• 听起来太复杂了，依靠图书馆做一些简单的事情吗？

Answer 1

在您描述的抽象层次上，这听起来像是一个合理的解决方案，并且有助于一些好的设计模式（如松散耦合和实例不变性）。据我所知，Guice不会对任何可比较的解决方案造成更大的内存泄漏或其他性能问题的威胁 - 只需关注您保留哪些引用，以便GC能够完成其工作。

为此，您可能需要注意在Guice中创建单例对象，但是，如果您依赖它们进行垃圾回收。只要Injector可以访问，声明为@Singleton（或asEagerSingleton或toInstance）的对象就不能被垃圾收集，因为Injector有义务返回完全相同的实例再次问道。在桌面虚拟机中，获取无状态对象的多个实例可能更便宜，因此GC可以全部收集它们，而不是将对象声明为永远无法收集的单例。