在Java中提高性能时应该注意什么？
我在一个大项目的维护团队工作（大约7k+班），我的日常工作主要是修复bug。不过，有时候我没有虫子来工作。当这种情况发生时，我大部分时间都在寻找代码中的性能差距。事实上，我有7000多个类要查找，这意味着找不到这些差距
因此，我想知道，在试图提高系统性能时，我应该寻找哪些简单的方法
我不是问具体的代码技术，而是问一般的技术。例如：
- 我已经查找了所有类似
String a = new String("")的代码，并更改为StringBuilder a = new StringBuilder(); - 我已经将对数据库的所有访问权限（如果适用）更改为使用
PreparedStatement - 所有的
Debug日志记录都被删除，并且Finest日志记录在可能的情况下被删除
如您所见，这些更改很容易进行，因为它们不需要测量系统性能——我唯一需要做的就是在Eclipse中使用搜索工具
# 1 楼答案
与其关注性能，不如使用以下一些静态分析工具来识别代码中的任何错误/潜在错误，并修复它们。这些有时有助于识别性能问题：
这两个插件都包括Eclipse插件
# 2 楼答案
不要只是环顾代码，改变事情。 正如其他人所说，在证明性能问题所在之前，不要修复它们
I use this simple method.
对于7000多个类，我敢打赌你的系统设计过度，而且你有太多抽象层的性能问题
发生的情况是，简单的函数和方法调用看起来是无辜的，事件处理代码被认为是“前沿”，但如果运行它并等待它变慢，然后“暂停”几次，您会看到如下情况：
有时深20-30层
如果可以避免出现在多个样本上的这些层中的任何一层，都可以节省大量的执行时间
# 3 楼答案
这是一个值得称赞的目标，但你需要关注实际的、可证明的绩效问题——而不是你“认为”的绩效问题所在
花时间在剖析器中找出真正的问题。。。然后从那里开始。否则，你只是在乱写代码，根本不知道自己是否产生了可衡量的影响
即使你有一张“在不衡量系统性能的情况下需要改变的事情”的清单，你真的相信它们适合你的情况吗
在您的情况下，我建议您花时间构建测试线束/性能仪器，这样您就可以看到哪里能让您的成本得到最大的回报
编辑： 为了解决“我知道使用事先准备好的声明会更快”的反对票和情绪——而不是要求获得银弹，当面对这个问题时，一个更好的问题是“我应该如何最有效地利用空闲时间让事情变得更好？”OP显然想改善这种情况，这很好。。。但是没有测量“哪里痛”，他实际上是在黑暗中射击。准备好的声明是否更快？当然——但如果真正的性能小精灵在其他地方，为什么要花时间“修复”DB代码，因为你可以通过追踪实际的痛点来产生真正的影响
还有一件事：在OP所描述的稳定系统中，由于引入的风险，在没有良好的量化理由的情况下进行代码更改通常被认为是不好的做法。在这种稳定的系统中，任何代码更改都必须考虑风险/回报问题。风险是巨大的：许多“简单的，不能破坏任何东西”的更改都会导致发布进度下滑/引入重大问题。奖励？不确定，因为你实际上不知道你的改变是否是导致绩效提升的原因。因此，我们对代码进行分析，以确保我们正在改进代码，这一点很重要
# 4 楼答案
不要因为事情“看起来”可行就盲目地改变
想想这个：
如果简单而盲目地删除该语句，对象将无法初始化
当然，这种说法一开始是错误的，但是，相信我，它们是存在的！！！！如果这样的事情发生在你身上会让你的生活很悲惨
更好的方法是使用探查器，找出哪些对象/方法/调用消耗了更多的时间/内存等，并尝试找出瓶颈
如果您有>；7k类很可能你只是在修复一堆根本没有被使用的代码
个人资料
# 5 楼答案
一般来说，仅仅查看代码库并试图通过查找某些东西来提高性能，并不能保证获得可测量的性能增益
通常，更有益的做法是使用探查器找出哪些代码段运行得最多，或者相反，找出哪些代码段运行时间最长，然后寻找优化这些区域的方法。这将产生最大的好处
# 6 楼答案
如果存在性能问题，那么@DarkSquid和@AlbertoPL的建议是正确的。如果不是这样，也许你最好把时间花在为将来的修改准备代码上。比如分析测试覆盖率，尤其是单元测试覆盖率，比如评估圈复杂度，或者只是查看报告错误最多的类（或者最大的类，或者其他一些简单的度量）。这样的主动分析可以让维护变得更容易