此问题是Java依赖项不是静态的，而是动态的。我读了这个stackoverflow link，但这是关于静态依赖关系和谷歌搜索获得类似的结果。
所以这是我的问题：
这是一个非常大的项目（20K + Java文件），运行了10年，目前有50多名开发人员。这里重新架构一直在发生，所以你有一个新的堆栈和一堆旧的层。大多数情况下，风险缓解意味着你不能直接摆脱课程，而是calle方法保持对新老课程的调用。开发人员的标准指令是：在生产环境中执行应用程序时不应调用旧类。
目前的解决方法：
他们所做的就是在老班上留下一个“假旗”，祈祷它不会被召唤。如果它（因为开发人员可能会错过指向新类）并且生产中的事情失败，那么将旧类的标志设置为true，并且世界上的一切都没有问题。 （这样他们只需更改一个具有标志但不必重新编译的属性文件）在prod中进行一年左右的测试后，他们就会放弃旧的类文件。现在这可能不是技术上最好的方法，但在实践中使用任务关键型应用程序时，你不会冒险，没有人能够记住/知道这些20K类在Java中甚至功能上做了什么。
我在寻找什么：
找出未使用的类的工具或方法。
现在这在某种程度上是鸡蛋，直到你执行某个罕见的场景，你不会发现在运行时调用哪个旧类，因此现有的解决方案。
如果您使用PMD等静态代码分析工具，他们不会告诉您未使用的，因为它们实际上是由某些或其他类调用，至少在代码级别。
也许，它只是疯狂的想法，一些从顶层动作层开始遍历所有依赖链/树的工具，并获得结果
当然，反应方式是构建一个完全自动化的回归测试套件并运行所有可能的场景，由于预算，人为限制等原因，遗憾的是这里不可能。
我需要的是一种优化我的代码的主动方式。也许这是一厢情愿的想法，这甚至是可能的，但我有一种唠叨的感觉，这个问题不是随机的，有点结构化，所以可能在某处有解决方案。
任何想法都赞赏。 !!
答案 0 :(得分：2)
由于动态类加载和反射，可能无法为此获得正确的解决方案。你可以从JBoss Tattletale开始。它可能也可用作声纳插件。它可以显示未使用的jar，但它只进行静态代码分析，这样你就会得到一些错误的错误。但是当你浏览列表时，你可以忽略诸如spring-security等之类的东西，但是当你找到自己的jar时，很可能你会知道该模块中是否没有动态类加载或反射