我目前有一个命令行工具，它大量使用 Guice 及其扩展。
完成该工具的功能后，我确定性能不达标，并开始使用简单的 hprof 进行分析。
这已经指出，仅仅创建 Injector 就是一个重大的性能问题。我通常避免在模块中做任何实际工作，并为提供者保留计算密集型工作......
鉴于此，Guice 的一些一般性能指南是什么？我应该避免使用@AssistedInject 和 FactoryModuleBuilders 吗？如果可能，避免使用@Singletons？确保所有绑定都是显式的并避免 JIT 绑定？
我已经到处搜索了，但除了人们说它非常快之外，真的找不到太多解决基本 Guice 性能的问题。
首先，您的问题还有很多不足之处。什么是“不合标准”的表现，你是如何决定这意味着什么的？是任意的吗？您是否有用户认为它太慢了？用户交互是否需要很长时间才能开始或太长时间才能产生结果？
如果没有要评估的实际代码，就很难调试性能问题。以下是我的一些经验提示：
只创建一次注入器。我看到一个项目，他们为每个 REST 请求创建一个注入器，但它的性能很糟糕。当他们停止这样做时，他们的 API 速度提高了 15 倍。如果您需要通过代码创建多个注入器，我强烈建议您进行重构，这样您就不需要了。
单例可以很好地提高性能，只是不要滥用它。它们只创建一次，这可能会在您创建注入器（急切的单例）或对象图中的其他东西第一次请求它们时发生。
了解 Guice 是一个基于反射的库，并且反射总是很慢。Guice 在运行时非常快，但在创建注入器时会以大量反射为代价（参见第 1 条）。如果您在应用程序中看到明显的滞后，这可能意味着您做错了什么。
最后，如果您决定无法处理 Guice 的性能“问题”，您可以尝试其他替代方案，例如来自Square（第 1 版）和Google（第 2 版）的 Dagger。它使用代码生成而不是反射，因此您没有反射成本，但它的功能并不完整，也没有扩展。