2023年京东黑客马拉松海选文稿

结果，小组第一。

各战队队长，大家好！本场海选答辩由主持人姜雪@姜雪 和志愿者王伟娜@王伟娜 为大家提供支持，感谢大家的配合！@全体成员

本场答辩场次【后端3场-9组】，答辩战队共 27 支

答辩时间：8月22日（下周二）13：30-18：00

会议室：忆吹箫（总部2号楼B座北塔6层）

【各战队答辩时间顺序】https://joyspace.jd.com/sheets/pjtSGPxFg7mJzNzJQG2e

！！！如需线上答辩请在表中标注，时间截止：今天下班前，请尽可能现场答辩，线上答辩有可能影响评审效果

答辩流程：

1）战队代表会议室门前至少提前5分钟等候答辩，志愿者会提醒

2）按战队依次入场，开始方案讲解（6分钟，已为大家备好电脑和PPT，直接讲解即可，无需携带电脑）

3）评委问答（2分钟）

4）退场，评委打分（1分钟）

5）引导下一个战队进场答辩

注意事项：

1）请提前做好演练，答辩过程严格遵守时间（剩余1分钟提醒），现场计时，超时将会直接打断#E-so07

2）海选评审侧重点：创新性40%、聚焦性/20%、业务贡献/30%、孵化潜力/10%；

2）答辩顺序按照大赛组委会随机分组顺序进行不做调整，除不可抗力等极特殊情况；

3）未按时按序答辩的战队根据报备情况依次顺延至本场最后答辩(仅允许顺延一次)，现场所有战队答辩结束后，顺延战队5分钟内未到场视为弃权#E-so07

4）每只战队一人答辩，参与问答总人数不超过三人(包括答辩人在内)；

5）为保障评审的顺利进行与公平公正性，请您严肃、严谨对待本次海选答辩，提前10-15分钟到达答辩会议室附近等待。

总计6分钟，问答2分钟，打分1分钟。

page1（10s）：各位评委、同事们好，我本次2023黑马答辩的项目是JDebugger，主题是效率-后端。主持人，下一页。

page2（5s）：接下来我将按照下面5个部分对jdebugger进行介绍。下一页。

page3（5s）：这是我们本次参赛队伍的简单介绍，下一页。

图

page4（35s）：我们首先来看一下项目简介，jdebugger是一种无需额外开通端口就能够让开发人员在Web端对预发、甚至是生产环境的Java代码进行调试的轻量级debug工具。它不仅支持基础的debug能力如step over下一步、step into进入、step out跳出方法、resume释放到下一个断点、flush等；同时还支持一些自主实现的高级能力， 比如支持两种调试模式，即一人调试多人围观以及多人并行调试模式，同时还支持热替换的能力。

右侧是我们预期实现的原型图，目标是复刻类似传统的IDE调试界面。

原型图中

左侧是路径树列表，

右侧是源码显示区域，源码中支持对代码行设置或者取消断点，当该行发生断点时，线程将会在此处进行block，并且源码显示区域将自动跳转并滚动到该断点的源码处。

左下角显示当前所有已设置的有效断点列表，以及调试栈信息和支持的断点全局操作功能，例如我们可以mute所有断点，表示当前请求里所有断点都不生效，或者clear所有断点，当点击其中某个断点时，源码显示区域也会和断点发生时一样，自动跳转并滚动至该断点的源码处。

右下角是本次断点触发时所有可触及变量的打印信息，比如局部变量、实例变量、类变量等，切换console tab查看当前执行日志的输出以及一些调试能力按钮列表。

右上角是支持的高级能力，比如热替换以及单人、多人两种模式的切换等。下一页。

page5（180s）：本次黑马将jdebugger作为项目的主要原因是，我们在调研了其他公司的java web debugger能力，发现市面上相关开源的工具很少。而基于IDE的remote debug需要开设socket端口，在京东内部需要配合堡垒机才能使用，整个调试流程较为繁琐，这种IDE的调试方式也不支持多人同时调试，且依赖于本地环境。开发为了能在预发、线上排查问题，一般都是通过增加日志，打包、发布并重试请求看日志来发现问题，这种流程不仅耗时而且费力。了解到京东目前没有Java Web Debugger相关工具或能力的建设，而且京东开发人员又大都是Java技术栈，所以jdebugger提上日程。

jdebugger创新点：

第一个是使用方便：无需额外开通端口，通过浏览器即可访问和使用，避免了本地与服务器代码不一致，而且无需本地环境即可调试。

支持环境隔离：编译环节做到预发、线上环境隔离，配合color灰度能力（指定PIN）可以对线上环境（指定机器）进行调试。

支持条件断点：比如支持>、<、>=、<=、==等表达式。

支持两种模式例如单人调试多人围观、多人并行调试，彼此互不干扰。

支持文件搜索、鼠标点击触达目标文件。

支持每步断点的上下文跟踪，实时捕获Java应用程序的调用链信息、变量值以及方法耗时等。

支持上传修复后的class文件进行热替换，快速支持调试。

支持无需手动再次触发请求，我们可选择将曾经的请求再次进行重放等等。下一页

业务贡献(30s)：业务贡献我们总结有3点，第一是成本、效率，工具主要是帮助开发在自测、链条、测试、上线阶段快速定位和修复代码中的问题，从而提高研发效率，同时在预发调试中无需申请额外的负载均衡资源。在多人并行调试的模式下呢，多个人同时进行调试也无需申请更多的服务器资源。第二点覆盖人群，我东目前大部分是java开发工程师，所以这个工具应用后覆盖面较广。第三点是这个工具拥有独立的知识产权，不受开源协议的约束。下一页。

方案详细介绍（120）：接下来是方案介绍，我们通过在javac编译期间，通过AST注入debug ability到class内，并deploy到容器中，用户通过front end servlet请求触达debug context，并在jvm执行时根据前端用户执行的操作对debug context进行控制。我们在多人并行的逻辑里，通过不同用户名生成彼此独立的debug context。为了区分预发和线上环境，我们在compile时加入-D参数，如果没有加入这个参数，则该环境的debug能力不生效。右上角我们可以通过hotswap按钮上传class文件，并对发现的bug进行修复，用于快速支持预发环境的调试和验证。下一页。

最终page（5s）上面就是我们本次黑马答辩的全部内容，主持人。

评委问题：

• 怎么解决本地与服务器代码不一致的问题？
• 源码是在一个jar里？
• 有没有专利的约束？
• 相较于本地debug有什么优点？