JVM Sandbox 入门教程与原理浅谈

在日常业务代码开发中，我们经常接触到 AOP，比如熟知的 Spring AOP。我们用它来做业务切面，比如登录校验，日志记录，性能监控，全局过滤器等。但 Spring AOP 有一个局限性，并不是所有的类都托管在 Spring 容器中，例如很多中间件代码、三方包代码，Java 原生代码，都不能被 Spring AOP 代理到。如此一来，一旦你想要做的切面逻辑并不属于 Spring 的管辖范围，或者你想实现脱离 Spring 限制的切面功能，就无法实现了。

那对于 Java 后端应用，有没有一种更为通用的 AOP 方式呢？答案是有的，Java 自身提供了 JVM TI，Instrumentation 等功能，允许使用者以通过一系列 API 完成对 JVM 的复杂控制。自此衍生出了很多著名的框架，比如 Btrace，Arthas 等等，帮助开发者们实现更多更复杂的 Java 功能。

JVM Sandbox 也是其中的一员。当然，不同框架的设计目的和使命是不一样的，JVM-Sandbox 的设计目的是实现一种在不重启、不侵入目标 JVM 应用情况下的 AOP 解决方案。

是不是看到这里还是不清楚我在讲什么？别急，我举几个典型的 JVM-Sandbox 应用场景：

• 流量回放：如何录制线上应用每次接口请求的入参和出参？改动应用代码固然可以，但成本太大，通过 JVM-Sandbox，可以直接在不修改代码的情况下，直接抓取接口的出入参。

• 安全漏洞热修复：假设某个三方包（例如出名的 fastjson）又出现了漏洞，集团内那么多应用，一个个发布新版本修复，漏洞已经造成了大量破坏。通过 JVM-Sandbox，直接修改替换有漏洞的代码，及时止损。

• 接口故障模拟：想要模拟某个接口超时 5s 后返回 false 的情况，JVM-Sandbox 很轻松就能实现。

• 故障定位：像 Arthas 类似的功能。

• 接口限流：动态对指定的接口做限流。

• 日志打印

• ...

可以看到，借助 JVM-Sandbox，你可以实现很多之前在业务代码中做不了的事，大大拓展了可操作的范围。

本文围绕 JVM SandBox 展开，主要介绍如下内容：

• JVM SandBox 诞生背景

• JVM SandBox 架构设计

• JVM SandBox 代码实战

• JVM SandBox 底层技术

• 总结与展望

JVM Sandbox 诞生背景

JVM Sandbox 诞生的技术背景在引言中已经赘述完毕，下面是作者开发该框架的一些业务背景上是一种 AOP 落地形式。那么可能有同学会问：已有成熟的 Spring AOP 解决方案，阿里巴巴为什么还要“重复造轮子”？这个问题要回到 JVM SandBox 诞生的背景中来回答。在 2016 年中，天猫双十一催动了阿里巴巴内部大量业务系统的改动，恰逢徐冬晨（阿里巴巴测试开发专家）所在的团队调整，测试资源保障严重不足，迫使他们必须考虑更精准、更便捷的老业务测试回归验证方案。开发团队面临的是新接手的老系统，老的业务代码架构难以满足可测性的要求，很多现有测试框架也无法应用到老的业务系统架构中，于是需要新的测试思路和测试框架。

为什么不采用 Spring AOP 方案呢？Spring AOP 方案的痛点在于不是所有业务代码都托管在 Spring 容器中，而且更底层的中间件代码、三方包代码无法纳入到回归测试范围，更糟糕的是测试框架会引入自身所依赖的类库，经常与业务代码的类库产生冲突，因此，JVM SandBox 应运而生。

JVM Sandbox 整体架构

本章节不详细讲述 JVM SandBox 的所有架构设计，只讲其中几个最重要的特性。详细的架构设计可以看原框架代码仓库的 Wiki。

类隔离

很多框架通过破坏双亲委派（我更愿意称之为直系亲属委派）来实现类隔离，SandBox 也不例外。它通过自定义的 SandboxClassLoader 破坏了双亲委派的约定，实现了几个隔离特性：

• 和目标应用的类隔离：不用担心加载沙箱会引起原应用的类污染、冲突。

• 模块之间类隔离：做到模块与模块之间、模块和沙箱之间、模块和应用之间互不干扰。

无侵入 AOP