这个问题是Java依赖不是静态的，而是动态的。我读了这个stackoverflow 链接，但这是关于静态依赖的，谷歌搜索得到了类似的结果。
所以这是我的问题：
这是一个非常大的项目（20K+ Java 文件），运行了 10 年，现在有 50 多名开发人员。在这里，重新架构一直在发生，所以你有一个新的堆栈和一个旧的层堆栈。大多数情况下，风险缓解意味着您不能立即摆脱一个类，而是 calle 方法保持对新旧类的调用。对开发人员的标准指令是：在生产环境中执行应用程序期间不应调用旧类。
当前解决方法：
他们所做的是在旧班级上保留一个“假标志”并祈祷它不会被调用。如果确实如此（因为开发人员可能会错过指向新类的操作）并且在生产中出现问题，那么将针对旧类的标志设置为 true 并且世界上一切都很好。（这样他们只需更改具有标志的属性文件而不必重新编译）在产品中进行了一年左右的此类测试后，他们放弃了旧的类文件。现在这在技术上可能不是最好的方法，但在实践中，对于任务关键型应用程序，您不会冒险，没有人能够记住/知道这些 20K 类在 Java 中甚至在功能上做了什么。
我在找什么：
找出未使用的类的工具或方法。
现在这在某些方面是一个鸡蛋，因为在您执行某个罕见的场景之前，您不会发现在运行时调用了哪个旧类以及现有的解决方案。
如果您使用 PMD 等静态代码分析工具，它们不会告诉您未使用的工具，因为它们实际上至少在代码级别被某些或其他类调用。
也许，它只是疯狂的想法，一些从顶层动作层开始遍历所有依赖链/树并得到结果的工具
当然，被动的方式是构建一个完全自动化的回归测试套件并运行所有可能的场景，不幸的是，由于预算、人力限制等原因，这在此处是不可能的。
我需要的是一种积极主动的方式来优化我的代码。也许这是一厢情愿的想法，这甚至是可能的，但我有一种唠叨的感觉，这个问题不是随机的，也不是结构化的，所以在某个地方可能会有解决方案。
任何想法表示赞赏。！！