JRebel 深度科普：为什么它能热加载新类，却改不动一个小小的 URL？

JRebel 深度科普：为什么它能热加载新类，却改不动一个小小的 URL？

作为 Java Web 开发者，你一定有过这样的疑惑：

用了 JRebel 后，我在 Service 里写了新方法、加了新类、甚至在内部类里写了复杂的逻辑，按一下编译，几毫秒就生效了。

但是，一旦我把 Controller 里的 @RequestMapping(“/v1/login”) 改成 /v2/login，或者改了 Servlet 的 @WebServlet 路径，刷新浏览器往往是 404，非得逼我重启（或重载应用）。

这到底是为什么？是 JRebel 有 Bug 吗？

其实，这背后隐藏着“字节码增强”与“框架初始化机制”之间的博弈。

一、 JRebel 的魔法：它如何搞定“代码”？

首先，我们要明白 JDK 原生的热加载（HotSwap）为什么弱。原生 JVM 规定：一旦一个类被加载（Loaded），它的内存结构（骨架）就定死了。你只能改方法里面的“肉”（指令），不能动骨头（字段、方法签名）。

JRebel 之所以能打破这个限制，是因为它根本没有遵守“定死”的规则。

1. “版本控制”式的类加载

当你启动 JRebel 时，它通过 -javaagent 潜入 JVM，接管了 ClassLoader（类加载器）。

对于 JRebel 代理的类，它会在内存中维护一个**“多版本映射”**。

• 新增方法/参数：

  当你修改代码并编译，JRebel 发现 .class 变了。它不会试图去“硬塞”进旧的类对象里，而是生成一个新的类版本（比如 UserClass_v2）。

• 调用重定向：

  所有对旧类的调用，都会通过 JRebel 注入的中间层（Proxy），自动路由到最新的 v2 版本上。

这就是为什么你新增方法、修改参数类型、甚至增加成员变量都能生效。在 JVM 看来，这其实是不断在加载“新”的东西，而不是在破坏“旧”的结构。

2. 新增类（New Class）与内部类（Inner Class）

• 新增类：对 JRebel 来说，加载一个从未见过的.class文件是最简单的，直接让 ClassLoader 读进来注册即可。
• 内部类：在编译后，内部类其实就是Outer$Inner.class。对 JRebel 来说，这和普通类没区别，也是直接加载。

结论：只要属于“代码逻辑”范畴（Java 字节码执行流），JRebel 都能通过动态字节码技术完美 Hold 住。

二、 JRebel 的软肋：为什么改 Mapping 经常翻车？

现在问题来了。既然代码都能改，为什么改个 URL 路径（Mapping）这么难？

因为“代码”是运行时跑的，而“映射”是启动时存的。

1. 框架的“贪婪”初始化

不管是 Tomcat、Spring MVC 还是 Spring Boot，它们都有一个共同特点：启动慢。

为什么慢？因为它们在启动时做了一次极其繁重的**扫描（Scanning）**工作。

• Tomcat 启动时：扫描所有@WebServlet，生成一张静态的路由表 (URL Map)。
• Spring 启动时：扫描所有@Controller、@RequestMapping，生成HandlerMapping 注册表。

关键点来了：

这张表生成后，通常是缓存在内存里的，并且设计初衷就是只读的。框架默认不会再去回头看一眼 Class 文件。

2. 时空错位的尴尬

当你把/rebel改成/rebel3并编译：

1. JRebel 层面（代码层）：成功了！内存里的Servlet类对象确实更新了，注解属性也变成了/rebel3。
2. 框架层面（配置层）：Tomcat/Spring 还在查它兜里那张旧的路由表。
   • 用户请求/rebel3-> Tomcat 查表 -> “没记录” ->404。
   • 用户请求/rebel-> Tomcat 查表 -> “有记录，找UserServlet” -> 调用成功（尽管 Servlet 类上的注解已经变了，但路由表没变）。

3. JRebel 的尝试与妥协

JRebel 并不是完全不支持改 Mapping，它内置了针对 Spring、Tomcat 的插件（Plugins）。

它的逻辑是：一旦检测到注解变了，就试图去“暴力”清空框架的缓存，强迫框架重新扫描。

但是，这非常危险且困难：

• 复杂性爆炸：Spring 的版本太多了，初始化逻辑千奇百怪，强行重置可能导致 AOP 失效、事务管理器断开等诡异 Bug。
• Context Reload（应用重载）：为了稳妥，JRebel 往往选择触发一次“轻量级重启”（Reload Context）。这会导致 Session 清空、Filter 链重组。如果你没配置好，或者项目太复杂，这个重载过程本身就会失败，导致看起来“热加载没生效”。

三、 总结与最佳实践

原理总结

• 新增 Class/方法/内部类：属于**“类加载机制”**的范畴。JRebel 通过魔改字节码和 ClassLoader，实现了完美的动态替换。
• 修改 Mapping/配置：属于**“框架状态管理”**的范畴。这需要框架配合刷新内存缓存，难度极大，往往需要触发应用上下文重载。

开发者该怎么办？

1. 分清边界：

   • 改业务逻辑（Service/Dao/算法）：放心改，秒级生效。
   • 改接口定义（Controller URL/参数注解）：做好心理准备，可能不生效。

2. 强制刷新大招：

   如果你修改了 @RequestMapping 却不想重启，可以试着去触碰一下 web.xml（加个空格保存）或者 application.properties。JRebel 监控到核心配置文件变动，通常会触发 Context Reload，这比重启快，而且能强制刷新路由表。

3. 心态调整：

   不要指望 JRebel 能解决 100% 的重启。它帮我们解决了 90% 的“逻辑修改”重启，剩下的 10% “配置修改”，老老实实点一下 Restart，也是一种休息。