一般Guice表现指南

Question

我目前有一个命令行工具,它使用Guice及其扩展程序.

完成该工具的功能后,我确定性能不合标准,并使用简单的hprof开始分析.

这已经指出,仅创建Injector是一个重要的性能问题.我通常避免在模块中做任何实际工作,并为Providers保留计算密集型工作......

有了这个,Guice的一般性能指南是什么？我应该避免使用@AssistedInject和FactoryModuleBuilders吗？尽可能避免@Singletons？确保所有绑定都是显式的并避免JIT绑定？

我一直在搜索,但除了人们说它真的很快之外,它无法真正找到解决基本Guice性能的问题.

Answer 1

首先，你的问题还有很多不足之处。什么是“不合标准”的表现？您如何确定这意味着什么？是任意的吗？您是否有用户认为速度太慢？是否需要很长时间才能启动或从用户交互中产生结果？

如果没有实际的代码进行评估，就很难调试性能问题。以下是我的经验中的一些提示：

1. 仅创建注入器一次。我看到一个项目，他们为每个 REST 请求创建一个注入器，但它的性能很糟糕。当他们停止这样做时，他们的 API 速度提高了 15 倍。如果您需要通过代码创建多个注入器，我强烈建议您进行重构，这样您就不需要这样做了。

2. 单例可以很好地提高性能，但不要滥用它。它们仅创建一次，一旦您创建注入器（热切的单例）或对象图中的其他内容首次请求它们时，就会发生这种情况。

3. 了解 Guice 是一个基于反射的库，而反射总是很慢。Guice 做得非常出色，运行时速度非常快，但代价是创建注入器时需要进行大量反射（请参阅第 1 项）。如果您在应用程序中发现明显的滞后，则可能意味着您做错了什么。

最后，如果您决定无法处理 Guice 的性能“问题”，您可以尝试使用Square（版本 1）和Google（版本 2）的 Dagger 等替代方案。它使用代码生成而不是反射，因此您没有反射成本，但它的功能不全，并且没有扩展。