代码盘点 (Code Inventory) 是 Azul JVM 的一项新功能，可帮助开发团队减少需维护的代码量。这是唯一能将 Java 应用程序在生产中使用的源代码精确编入目录的解决方案，可轻松准确地识别需要删除的死代码。
代码盘点功能可从 JVM 内部（类/包和方法级别）收集详细信息，而不会因传统性能分析器造成性能损耗，因此您可以全面查看企业 Java 工作负载随时间推移运行的具体代码。这相当于提供了一个定位死代码的精确“藏宝图”，您的工程团队可以放心据此删除死代码。
未使用的代码或死代码不会影响应用程序的性能，为什么一定要删除它们？这其实很重要，因为开发者也是人，每次不得不处理失效代码或试图弄清杂乱代码的作用，就是在浪费宝贵的时间。若在遥远的未来，所有代码全由 AI 编写，那时开发者就不会在乎这些，我也会失业，但在那之前，他们不会愿意让这些累赘拖累自己。
这看似是小事。用鼠标滚过无关代码或处理这些代码需要多少时间？
假设一位开发者每次处理死代码需要 30 秒，每小时要处理四次。每小时 2 分钟，一天 8 小时就是 16 分钟。研究显示，出现一次分心后，需要 23 分钟才能再次将注意力完全拉回到工作上。
除了工作效率降低，死代码还会导致挫败感、士气低落和员工流失。
团队为何不删除死代码
没有人想要增加死代码，但开发项目增量被称为“冲刺”是有原因的。随着时间的推移，我们都会更改方法，注释掉注解，或者以绕过某些类或方法的方式重构代码。虽然花在滚动浏览和思考这些功能上的时间可能很少，但当团队需要更新库或升级主要 Java 版本时，花费的时间就会大大增加。这时，团队就会积极使用原本的死代码来修复编译错误或测试失败，但由于这些代码永远不会在生产中运行，这些操作不会产生任何益处。
在成功企业中，应用程序和功能逐年增多，每个项目的规模和复杂性也随之增加。团队花时间写新代码却很少清除旧代码。开发者通常不会删除旧代码，因为这样做的风险太大：如果有什么要调用该 Java 功能，却因代码被删除而无法调用呢？
为删除死代码而进行分析是一项耗时、枯燥、令人心力交瘁的工作。如果这正是您的工作，我无意冒犯，但比起让团队做这件事，Azul 代码盘点可以将第一方法执行集合集中在一起，以便定位不在生产中运行的代码。代码盘点可提供用于删除代码的藏宝图。
有些团队确实会通过几种技术来处理死代码。一种是静态死代码分析，可以识别无法访问的代码。如果一个方法是私密的，则只能通过它的类来调用。如果没有调用，该方法很可能是无效的。虽然这是种有效方法，但却只基于可访问性：如果方法是公共的，则理论上可以被调用；或者如果整个类都未被使用……
代码盘点的工作原理
代码盘点可识别低至方法级别的代码，并展示出在工程师确定的时间段内已在生产中运行和未在生产中运行的代码的准确记录。这能省去搜索和分析代码库的时间。现在，工程师只需将代码与代码盘点记录进行比较，就能像对照藏宝图一样找到确认符合删除条件的代码。
- 应用程序在 Azul JVM 上运行，启用了代码盘点
- 数据通过转发器到达收集点
- 每个客户的租户收集并汇总数据，标记每个方法首次出现和最后一次出现的日期和时间，以在不同运行之间提供可见性。
- 应用程序所有者可通过 REST API 调用 Code Inventory 来获取结果，并与自己的代码进行比较，以安排删除工作
我应在何处使用代码盘点？
收集代码盘点数据的最佳位置是生产系统，而非开发或测试环境。随着 TDD（Test-Driven Development，测试驱动开发）技术在业界的应用超过十年，一些原本的死代码仅因为单元测试而得以继续被使用。这增加了开发难度，因为删除死代码会导致产生不必要且实际具有误导性的测试失败警报。但其实，团队也可以将单元测试与代码一起删除。
由于 JVM 的运行方式，代码盘点对生产性能的影响可以忽略不计。该功能重新利用了 JVM 的“首次调用”功能，以记录正在调用的内容以及该方法的位置。这在 JVM 的每次执行中只发生一次，与程序执行异步。
衡量您自己的代码
代码盘点作为 Azul Vulnerability Detection（Azul 漏洞检测）的一项功能，已面向所有自 2023 年 4 月或之后运行 Azul JVM 的用户正式发布。如要设置收集盘点数据的云租户，请联系 Azul，我们可以协助您开启云租户。
