理论上，您无法确定地找到未使用的代码。这有一个数学证明(好吧，这是一个更普遍的定理的特殊情况)。如果你很好奇，可以查一下《停止问题》。

这可以在Java代码中以多种方式表现出来:

根据用户输入、配置文件、数据库条目等加载类; 加载外部代码; 将对象树传递给第三方库; 等。

也就是说，我使用IDEA IntelliJ作为我的IDE选择，它有广泛的分析工具，可以发现模块、未使用的方法、未使用的成员、未使用的类等之间的依赖关系。它也很智能，就像一个没有被调用的私有方法被标记为未使用，但一个公共方法需要更广泛的分析。

用户覆盖工具，例如EMMA。但它不是静态工具(也就是说，它需要通过回归测试实际运行应用程序，并通过所有可能的错误情况，这是不可能的:))

尽管如此，EMMA还是非常有用的。

我在Eclipse中对单个类所做的一件事是，将它的所有方法都更改为private，然后看看我得到了什么抱怨。对于所使用的方法，这将引起错误，我将它们返回到尽可能低的访问级别。对于未使用的方法，这将引发关于未使用方法的警告，然后可以删除这些方法。作为奖励，您经常会发现一些公共方法可以而且应该被私有。

但这是非常手工的。

CodePro最近由谷歌和Eclipse项目一起发布。它是免费的，而且非常有效。该插件具有一个/多个入口点的“查找死代码”功能。效果很好。

代码覆盖工具，如Emma、Cobertura和Clover，将检测您的代码，并记录通过运行一组测试调用代码的哪些部分。这是非常有用的，并且应该是开发过程中不可分割的一部分。它将帮助您确定测试套件对代码的覆盖程度。

然而，这与识别真正的死代码是不同的。它只识别被测试覆盖(或未被测试覆盖)的代码。这可能会给您带来假阳性(如果您的测试没有覆盖所有场景)和假阴性(如果您的测试访问了实际上从未在真实场景中使用过的代码)。

我认为真正识别死代码的最好方法是在实时运行的环境中使用覆盖工具，并在一段较长的时间内分析代码覆盖率。

If you are runnning in a load balanced redundant environment (and if not, why not?) then I suppose it would make sense to only instrument one instance of your application and to configure your load balancer such that a random, but small, portion of your users run on your instrumented instance. If you do this over an extended period of time (to make sure that you have covered all real world usage scenarios - such seasonal variations), you should be able to see exactly which areas of your code are accessed under real world usage and which parts are really never accessed and hence dead code.

我个人从来没有见过这样做，也不知道如何使用上述工具来检测和分析没有通过测试套件调用的代码——但我相信它们可以做到。

Eclipse Goto Windows >首选项> Java >编译器>错误/警告 把它们都改成错误。修复所有错误。这是最简单的方法。这样做的好处是，您可以在编写代码时清理代码。

截图Eclipse代码: