我必须调整一个Java EE应用程序，需要处理超过40 tps的事务。
在每个类中，我都会看到许多警告，例如未使用的变量，对泛型类型迭代器的引用应该参数化，导入...永远不会被使用，局部变量永远不会被读取，依此类推。
所有这些警告是否会导致应用程序出现任何性能缺陷？
Java是否足够聪明，不会创建一个从未在运行时使用过的变量？
*我对它进行了一些测试，似乎是一个内存占用应用程序;只需1/4的吞吐量，就可以在不到5分钟的时间内填充10GB的堆。
答案 0 :(得分：3)
什么都不会发生。您将继续处理肮脏且难以理解的代码。这可能是危险的：因为如果你不使用变量你可能想要使用它但是错误地使用了其他的，所以可能你的代码是错误的，这个错误将在星期五，6PM当你要去电影院时发现与你生命中的女孩...... :(。
修复3000个警告是可行的任务。我用大而肮脏的项目做了至少两次。可能需要一两天左右。如果我是你，我会这样做。
答案 1 :(得分：2)
完全取决于警告的内容和周围的代码。
“unchecked generic cast”之类的警告显然很好，因为它是编译器告诉你它不能保证泛型的类型安全 - 这最终会产生与“好”情况完全相同的字节码虽然。与“不必要的拆箱”之类的东西相同，编译器会为你插入相同的调用。
另一方面，诸如“永远不会读取本地变量”之类的警告最终可能反映出潜在的放缓。 Hotspot在它的优化方面非常惊人，但它可以承担的限制是有限的。这个特殊的警告也意味着你填充局部变量，并且通常这不能为一个非平凡的情况进行优化，因为它可能有副作用。然而，在没有副作用的情况下，计算是浪费周期，因为它永远不会被阅读。
但实际上，为什么要忽略这些警告呢？他们在那里是有原因的，没有任何借口可以帮助他们无论如何，请使用未参数化的Iterator。 （当底层集合的类型发生更改时，您希望代码在您更改迭代器读取代码之前不要编译。）
在奇怪的情况下，你无法避免警告，但你确定它没问题（这通常是转换为泛型类型的情况），然后使用@SuppressWarnings注释来处理这个问题。它不仅会导致编译器关闭，而且还会成为其他开发人员的标志，“这看起来有点狡猾，但它实际上已经是因为......”（并且几乎总是会有一个注释解释为什么）。
遇到警告时，您应该修复，在极端情况下将其标记为误报。理想情况下，编译器应始终返回零警告。
答案 2 :(得分：1)
我会忽略性能问题。还有一个很好的理由不忽视这些警告。
如果编译器给你那么多警告，并且你没有清理它们，那就意味着当你的代码存在合法问题时你就不会注意到，因为它们将被埋没在虚假错误消息中。一个优秀的软件工程师试图让他们的代码编译没有错误，只要这样他们可以注意到有一个合理的问题需要修复。
鉴于此处存在大量错误，我怀疑您可能确实存在错误海洋隐藏的代码中的实际错误，您应该修复它们。
答案 3 :(得分：1)
这些警告中指出的问题（至少你提到的那些）不太可能对性能产生任何直接影响。相反，它们表明低可维护性和糟糕的开发人员实践。警告和糟糕的表现都是同一根本原因的症状：不称职的开发人员。
修复这些警告不会使代码表现更好，但会使其更易于维护，因此更容易解决性能问题。
答案 4 :(得分：0)
大多数警告都是对编译时间问题的引用，这些问题不会影响性能，如果它们不会导致缺陷，就像你说的那样。 java编译器可能可能足够聪明，可以优化未使用的原语，但如果这些是类，所有的注意都会被关闭。
答案 5 :(得分：0)
如果你的程序使用10GB的堆，那么它要么处理大量数据，要么就是内存泄漏问题（是的，它们可能发生在Java中）。它可能与警告无关。
答案 6 :(得分：0)
3000警告==不称职的程序员==代码差= =在空间和时间上执行代码不好
警告是你最不担心的事情！
我仍然会努力解决这些问题，因为你必须审查它们周围的代码，并且可能会发现许多更严重的问题，所以这不是徒劳的。