有一些工具可以分析代码并提供代码覆盖率数据。这可以让您看到(当代码运行时)调用了多少代码。您可以使用任何这些工具来找出您有多少孤立代码。

我会让运行中的系统保持代码使用的日志，然后开始检查几个月或几年没有使用的代码。

例如，如果您对未使用的类感兴趣，那么所有的类都可以在创建实例时记录日志。然后，一个小脚本可以将这些日志与完整的类列表进行比较，以找到未使用的类。

Of course, if you go at the method level you should keep performance in mind. For example, the methods could only log their first use. I dont know how this is best done in Java. We have done this in Smalltalk, which is a dynamic language and thus allows for code modification at runtime. We instrument all methods with a logging call and uninstall the logging code after a method has been logged for the first time, thus after some time no more performance penalties occur. Maybe a similar thing can be done in Java with static boolean flags...

我们已经开始使用Find Bugs来帮助识别代码库中目标丰富的重构环境中的一些缺陷。我还会考虑结构101来识别代码库架构中过于复杂的地方，这样你就知道真正的沼泽在哪里。

有一个Java项目-死代码检测器(DCD)。对于源代码，它似乎工作得不太好，但对于.jar文件-它真的很好。另外，您可以通过类和方法进行过滤。

DCD不是某些IDE的插件，但可以从ant或独立运行。它看起来像一个静态工具，它可以做PMD和FindBugs不能做的事情。我会试试的。

附注:正如下面的评论中提到的，该项目现在存在于GitHub中。

代码覆盖工具，如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.

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