一、前言

在开始之前，我们先来模拟一下以下的场景：

小李：“小明，你的接口没有返回数据，麻烦帮忙看一下？”

小明：“我这边的数据也是从别人的服务器中拿到的，但是我不确定是因为逻辑处理有问题导致没有结果，还是因为我依赖的服务有问题而没有返回结果，我需要确认一下。”

小明：“哎呀，线上没有日志，我需要加个日志上个线。”

30分钟之后……

小明：“不好意思，日志加错地方了……稍等……”

接来下隆重登场的就是本文的主角JVM SandBox了。基于JVM SandBox，我们可以很容易地做到在不重新部署应用的情况下，给指定的某些类的某些方法加上日志功能。当然，动态加日志仅仅是JVM SandBox可以应用的一个小小的场景，JVM SandBox的威力远不在于此。那么，JVM SandBox是什么？JVM SandBox从哪里来？JVM SandBox怎么用？本文在第二章会回答这几个问题，如果你跟我一样对JVM SandBox的底层实现原理感兴趣，特别是JVM相关部分，那么第三章有相关的内容；如果你只想了解JVM SandBox自身具有哪些特性，以及JVM SandBox是如何设计实现的，那么可以跳过第三章，直接阅读第四章；最后，在第五章会简单地介绍其他两个可以应用JVM SandBox的场景。

二、JVM SandBox简介

2.1 AOP

在介绍JVM SandBox之前，我们先来回顾一下AOP技术。

AOP（面向切面编程，Aspect Oriented Programming）技术已被业界广泛应用，其思想是面向业务处理过程的某个步骤或阶段进行编程，这个步骤或阶段被称为切面，其目的是降低业务逻辑的各部分之间的耦合，常见的AOP实现基本原理有两种：代理和行为注入。

1）代理模式
在代理模式下，我们会创建一个代理对象来代理原对象的行为，代理对象拥有原对象行为执行的控制权，在这种模式下，我们基于代理对象在原对象行为执行的前后插入代码来实现AOP。

图2-1 代理模式

2）行为注入模式
在行为注入模式下，我们不会创建一个新的对象，而是修改原对象，在原对象行为的执行前后注入代码来实现AOP。

图2-2 行为注入模式

2.2 JVM SandBox

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

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

JVM SandBox本身是基于插件化的设计思想，允许用于以“模块”的方式基于JVM SandBox提供的AOP能力开发新的功能。基于JVM SandBox，我们不需要关心如何在JVM层实现AOP的技术细节，只需要通过JVM SandBox提供的编程结构告诉“沙箱”，我们希望对哪些类哪些方法进行AOP，在切面点做什么即可，JVM SandBox模块功能编写起来非常简单。下面是一个示例模块代码：

@MetaInfServices(Module.class)  
@Information(id = "my-sandbox-module")//模块名  
public class MySandBoxModule implements Module {  
    private Logger LOG = Logger.getLogger(MySandBoxModule.class.getName());  
    @Resource  
    private ModuleEventWatcher moduleEventWatcher;  
  
    @Command("addLog")//模块命令名  
    public void addLog() {  
        new EventWatchBuilder(moduleEventWatcher)  
                .onClass("com.float.lu.DealGroupService")//想要对DealGroupService这个类进行切面  
                .onBehavior("loadDealGroup")//想要对上面类的loadDealGroup方法进行切面  
                .onWatch(new AdviceListener() {  
                    @Override  
                    protected void before(Advice advice) throws Throwable {  
                        LOG.info("方法名: " + advice.getBehavior().getName());//在方法执行前打印方法的名字  
                    }  
                });  
    }  
}

如上面代码所示，通过简单常规的编码即可实现对某个类的某个方法进行切面，不需要对底层技术有了解即可上手。上面的模块被JVM SandBox加载和初始化之后便可以被使用了。比如，只需要告诉JVM SandBox我们要执行my-sandbox-module这个模块的addLog这个方法，我们编写的功能的调用就会被注入到目标地方。

JVM SandBox使用起来非常很简单，但是JVM SandBox背后所涉及到的底层技术原理、实现细节却不简单，比如Java Agent、Attach、JVMTI、Instrument、Class字节码修改、ClassLoader、代码锁、事件驱动设计等等。如果要深究可能要究几本书，但这不是本文的目的。本文仅仅概括性地介绍JVM SandBox实现涉及到的一些核心技术点，力求通过本文可以回答如JVMTI是什么？Instrument是什么？Java Agent是什么？它们之间有什么关系？他们和JVM SandBox又是什么关系等问题。

三、JVM核心技术

3.1 Java Agent

JVM SandBox容器的启动依赖Java Agent，Java Agent（Java代理）是JDK 1.5之后引入的技术。开发一个Java Agent有两种方式，一种是实现一个premain方法，但是这种方式实现的Java Agent只能在JVM启动的时候被加载；另一种是实现一个agentmain方法，这种方式实现的Java Agent可以在JVM启动之后被加载。当然，两种实现方法各有利弊、各有适用场景，这里不再过多介绍，JVM SandBox Agent对于这两种方式都有实现，用户可以自行选择使用，因为在JVM层这两种方式底层的实现原理大同小异，因此本文只选择agentmain方式进行介绍，下文的脉络也仅跟agentmain方式相关。下面先通过两行代码，来看看基于agentmain方式实现的Java Agent是如何被加载的：

VirtualMachine vmObj = VirtualMachine.attach(targetJvmPid);//targetJvmPid为目标JVM的进程ID  
vmObj.loadAgent(agentJarPath, cfg);  // agentJarPath为agent jar包的路径，cfg为传递给agent的参数

在Java Agent被加载之后，JVM会调用Java Agent JAR包中的MANIFEST.MF文件中的Agent-Class参数指定的类中的agentmain方法。下面两节会对这两行代码的背后JVM实现技术进行探究。

3.2 Attach

1）Attach工作机制

上面一节中第一行代码的背后，有一个重要的JVM支撑机制——Attach，为什么说重要？比如大家最熟悉的jstack就是要依赖这个机制来工作，那么，Attach机制是什么呢？我们先来看看Attach机制都做了什么事儿。首先，Attach机制对外提供了一种进程间的通信能力，能让一个进程传递命令给JVM；其次，Attach机制内置一些重要功能，可供外部进程调用。比如刚刚提到的jstack，再比如上一节中提到的第二行代码：vmObj.loadAgent(agentJarPath, cfg); 这行代码实际上就是告诉JVM我们希望执行load命令，下面的代码片段可以更直观地看到load命令对应的行为是：JvmtiExport::load_agent_library，这行代码的行为是对agentJarPath指定的Java Agent进行加载：

//来源:attachListener.cpp  
static AttachOperationFunctionInfo funcs[] = {  
  { "agentProperties",  get_agent_properties },  
  { "datadump",         data_dump },  
  { "dumpheap",         dump_heap },  
  { "load",             JvmtiExport::load_agent_library },  
  { "properties",       get_system_properties },  
  { "threaddump",       thread_dump },  
  { "inspectheap",      heap_inspection },  
  { "setflag",          set_flag },  
  { "printflag",        print_flag },  
  { "jcmd",             jcmd },  
  { NULL,               NULL }  
};

那么，JVM Attach机制是如何工作的呢？Attach机制的核心组件是Attach Listener，顾名思义，Attach Listener是JVM内部的一个线程，这个线程的主要工作是监听和接收客户端进程通过Attach提供的通信机制发起的命令，如下图所示：

图3-1 Attach Listener工作机制

Attach Listener线程的主要工作是串流程，流程步骤包括：接收客户端命令、解析命令、查找命令执行器、执行命令等等，下面附上相关代码片段：
片段一：AttachListener::init（启动AttachListener线程）：

//来源:attachListener.cpp  
{ MutexLocker mu(Threads_lock);  
    // 启动线程  
    JavaThread* listener_thread = new JavaThread(&attach_listener_thread_entry);  
    // Check that thread and osthread were created  
    if (listener_thread == NULL || listener_thread->osthread() == NULL) {  
      vm_exit_during_initialization("java.lang.OutOfMemoryError",  
                                    "unable to create new native thread");  
    }  
    java_lang_Thread::set_thread(thread_oop(), listener_thread);  
    java_lang_Thread::set_daemon(thread_oop());  
  
    listener_thread->set_threadObj(thread_oop());  
    Threads::add(listener_thread);  
    Thread::start(listener_thread);  
  }

片段二：attach_listener_thread_entry（轮询队列）：

//来源:attachListener.cpp  
static void attach_listener_thread_entry(JavaThread* thread, TRAPS) {  
  os::set_priority(thread, NearMaxPriority);  
  
  thread->record_stack_base_and_size();  
  
  if (AttachListener::pd_init() != 0) {  
    return;  
  }  
  AttachListener::set_initialized();  
  for (;;) {  
    AttachOperation* op = AttachListener::dequeue();// 展开  
    if (op == NULL) {  
      return;   // dequeue failed or shutdown  
    }

片段三：dequeue（读取客户端socket内容）

//来源:attachListener_bsd.cpp  
BsdAttachOperation* BsdAttachListener::dequeue() {  
  for (;;) {  
    int s;  
    // wait for client to connect  
    struct sockaddr addr;  
    socklen_t len = sizeof(addr);  
    RESTARTABLE(::accept(listener(), &addr, &len), s);  
    if (s == -1) {  
      return NULL;      // log a warning?  
    }  
    // 省略……  
    // peer credential look okay so we read the request  
    BsdAttachOperation* op = read_request(s);  
  }  
}

2）加载Agent

回到上层，我们再看看vmObj.loadAgent(agentJarPath, cfg)；这行Java代码代码是如何工作的？其实，这行代码背后主要做了一件事情：告诉Attach加载instrument库，instrument库又是什么？instrument库是基于JVMTI编程接口编写的一个JVMTI Agent，其表现形式是一个动态链接库，下面上两个代码片段：

//来源：HotSpotVirtualMachine.java  
//片段1  
loadAgentLibrary("instrument", args);  
//片段2   
InputStream in = execute("load",  
                                 agentLibrary,  
                                 isAbsolute ? "true" : "false",  
                                 options);

Attach接收到命令之后执行load_agent_library方法，主要做两件事情：1）加载instrument动态库；2）找到instrument动态库中实现的Agent_OnAttach方法并调用。Attach的工作到这里就结束了，至于Agent_OnAttach这个方法做了什么事情，我们会在JVMTI部分进行介绍。下面先解释Attach相关的另外一个问题，Attach Listener并不是在JVM启动的时候被启动的，而是基于一种懒启动策略实现。

3）Attach Listener懒启动

为方便理解下面引入代码片段，这是从JVM启动路径上截取的两片代码：

//来源:thread.cpp  
// 片段1  
  os::signal_init();  
  if (!DisableAttachMechanism) {  
    AttachListener::vm_start();  
    if (StartAttachListener || AttachListener::init_at_startup()) {  
      AttachListener::init();  
    }  
  }  
// 片段2  
bool AttachListener::init_at_startup() {  
  if (ReduceSignalUsage) {  
    return true;  
  } else {  
    return false;  
  }  
}

DisableAttachMechanism这个参数默认是关闭的，也就是说JVM默认情况下启用Attach机制，但是StartAttachListener和ReduceSignalUsage这两个参数默认都是关闭的，因此Attach Listener线程默认并不会被初始化。那么Attach Listener线程是在什么时候被初始化的呢？这就有必要了解一下Signal Dispatcher组件了，Signal Dispatcher本质上也是JVM提供的一种进程间通信机制，只是这种机制是基于信号量来实现的。

我们先从Signal Dispatcher的服务端角度，来看看Signal Dispatcher是如何工作的，不知道大家有没有注意到上面的os::signal_init()；这么一行代码，其作用是初始化和启动Signal Dispatcher线程，Signal Dispatcher线程启动之后就会进入等待信号状态（os::signal_wait）。如下代码片段所示，SIGBREAK信号是SIGQUIT信号的别名，Signal Dispatcher接收到这个信号之后会调用AttachListener的is_init_trigger的方法初始化和启动AttachListener线程，同时会在tmp目录下面创建/tmp/.attach_pid${pid}这样的一个文件，代表进程号为pid的JVM已经初始化了AttachListener组件了。

片段一：os::signal_init();（启动Signal Dispatcher线程）

//来源：os.cpp  
{ MutexLocker mu(Threads_lock);  
      JavaThread* signal_thread = new JavaThread(&signal_thread_entry);//展开  
      if (signal_thread == NULL || signal_thread->osthread() == NULL) {  
        vm_exit_during_initialization("java.lang.OutOfMemoryError",  
                                      "unable to create new native thread");  
      }  
      java_lang_Thread::set_thread(thread_oop(), signal_thread);  
      java_lang_Thread::set_priority(thread_oop(), NearMaxPriority);  
      java_lang_Thread::set_daemon(thread_oop());  
  
      signal_thread->set_threadObj(thread_oop());  
      Threads::add(signal_thread);  
      Thread::start(signal_thread);  
    }

片段二：signal_thread_entry（监听信号）

//来源：os.cpp  
static void signal_thread_entry(JavaThread* thread, TRAPS) {  
  os::set_priority(thread, NearMaxPriority);  
  while (true) {  
    int sig;  
    {  
      sig = os::signal_wait();  
    }  
    switch (sig) {  
      case SIGBREAK: {  
        // Check if the signal is a trigger to start the Attach Listener - in that  
        // case don't print stack traces.  
        if (!DisableAttachMechanism && AttachListener::is_init_trigger()) {//展开  
          continue;  
        }

片段三：is_init_trigger（启动AttachListener）

//来源：attachListener_bsd.cpp  
bool AttachListener::is_init_trigger() {  
  char path[PATH_MAX + 1];  
  int ret;  
  struct stat st;  
  snprintf(path, PATH_MAX + 1, "%s/.attach_pid%d",os::get_temp_directory(), os::current_process_id());  
  RESTARTABLE(::stat(path, &st), ret);  
  if (ret == 0) {  
    if (st.st_uid == geteuid()) {  
      init();//初始化Attach Listener  
      return true;  
    }  
  }  
  return false;  
}

我们再从客户端角度，来看看客户端是如何通过Signal Dispatcher来启动AttachListener线程的，这要又要回到 VirtualMachine.attach(pid)这行代码，这行代码的背后会执行具体VirtualMachine的初始化工作，我们拿Linux平台下的LinuxVirtualMachine实现来看，下面是LinuxVirtualMachine初始化的核心代码：

//来源：LinuxVirtualMachine.java  
//检查目标JVM对否存在标识文件  
path = findSocketFile(pid);  
if (path == null) {  
  File f = createAttachFile(pid);  
  try {  
    mpid = getLinuxThreadsManager(pid);  
    sendQuitToChildrenOf(mpid);

上面提到目标JVM一旦启动attach组件之后，会在/tmp目录下创建名为.java_pid${pid}的文件。因此，客户端在每次初始化LinuxVirtualMachine对象的时候，会先查看目标JVM的这个文件是否存在，如果不存在则需要通过SIGQUIT信号来将attach组件拉起来。具体操作是进入try区域后，找到指定pid进程的父进程（Linux平台下线程是通过进程实现的），给父进程的所有子进程都发送一个SIGQUIT信号，而Signal Dispatcher组件恰好在监听这个信号。

3.3 JVMTI

JVMTI(Java Virtual Machine Tool Interface)是一套由 Java 虚拟机提供的，为JVM相关的工具提供的本地编程接口集合。JVMTI是从Java SE 5开始引入，整合和取代了以前使用的Java Virtual Machine Profiler Interface (JVMPI) 和 the Java Virtual Machine Debug Interface (JVMDI)，而在 Java SE 6 中，JVMPI和JVMDI已经消失了。JVMTI 提供了一套“代理”程序机制，可以支持第三方工具程序以代理的方式连接和访问JVM，并利用JVMTI提供的丰富的编程接口，完成很多跟JVM相关的功能。JVMTI的功能非常丰富，包括虚拟机中线程、内存/堆/栈，类/方法/变量，事件/定时器处理等等。使用JVMTI一个基本的方式就是设置回调函数，在某些事件发生的时候触发并作出相应的动作，这些事件包括虚拟机初始化、开始运行、结束，类的加载，方法出入，线程始末等等。如果想对这些事件进行处理，需要首先为该事件写一个函数，然后在 jvmtiEventCallbacks 这个结构中指定相应的函数指针。
上面提到的Instrument就是一个基于JVMTI接口的，以代理方式连接和访问JVM的一个Agent，Instrument库被加载之后JVM会调用其Agent_OnAttach方法，如下代码片段：

//来源：InvocationAdapter.c  
//片段1：创建Instrument对象  
success = createInstrumentationImpl(jni_env, agent);  
//片段2：监听ClassFileLoadHook事件并设置回调函数为eventHandlerClassFileLoadHook  
callbacks.ClassFileLoadHook = &eventHandlerClassFileLoadHook;  
jvmtierror = (*jvmtienv)->SetEventCallbacks(jvmtienv, &callbacks, sizeof(callbacks));  
//片段3：调用java类的agentmain方法  
success = startJavaAgent(agent, jni_env, agentClass, options, agent->mAgentmainCaller);

Agent_OnAttach方法被调用的时候主要做了几件事情：1）创建Instrument对象，这个对象就是Java Agent中通过agentmain方法拿到的Instrument对象；2）通过JVMTI监听JVM的ClassFileLoadHook事件并设置回调函数eventHandlerClassFileLoadHook；3）调用Java Agent的agentmain方法，并将第1）步创建的Instrument对象传入。通过上面的内容可以知道，在JVM进行类加载的都会回调eventHandlerClassFileLoadHook方法，我们可以猜到eventHandlerClassFileLoadHook方法做的事情就是调用Java Agent内部传入的Instrument的ClassFileTransformer的实现：

//来源Instrumentation.java  
void addTransformer(ClassFileTransformer transformer);

通过JVMTI的事件回调机制，Instrument可以捕捉到每个类的加载事件，从而调用用户实现的ClassFileTransformer来对类进行转换，那么已经被加载的类怎么办呢？为解决这个问题，Instrument提供了retransformClasses接口用于对已经加载的类进行转换：

//来源Instrumentation.java  
void retransformClasses(Class<?>... classes) throws UnmodifiableClassException;

Instrument底层的实现实际上也是调用JVMTI提供的RetransformClasses接口，RetransformClasses实现对已经加载的类进行重新定义（redefine），而重新定义类也会触发ClassFileLoadHook事件，Instrument同样会监听到这个事件并对被加载的类进行处理。到这里，JVM SandBox底层依赖JVM的核心机制已经介绍完了，下面通过一张时序图将一个JavaAgent的加载过程涉及到的相关组件及行为串起来：

图3-2 Java Agent加载流程

四、JVM SandBox设计与实现

4.1 可插拔

本文理解的JVM SandBox可插拔至少有两层含义：一层是JVM沙箱本身是可以被插拔的，可被动态地挂载到指定JVM进程上和可以被动态地卸载；另一层是JVM沙箱内部的模块是可以被插拔的，在沙箱启动期间，被加载的模块可以被动态地启用和卸载。
一个典型的沙箱使用流程如下：

$./sandbox.sh -p 33342 #将沙箱挂载到进程号为33342的JVM进程上  
$./sandbox.sh -p 33342 -d 'my-sandbox-module/addLog' #运行指定模块, 模块功能生效  
$./sandbox.sh -p 33342 -S #卸载沙箱

JVM沙箱可以被动态地挂载到某个正在运行的目标JVM进程之上（前提是目标JVM没有禁止attach功能），沙箱工作完之后还可以被动态地从目标JVM进程卸载掉，沙箱被卸载之后，沙箱对对目标JVM进程产生的影响会随即消失（这是沙箱的一个重要特性），沙箱工作示意图如下：

图4-1 沙箱工作示意图

客户端通过Attach将沙箱挂载到目标JVM进程上，沙箱的启动实际上是依赖Java Agent，上文已经介绍过，启动之后沙箱会一直维护着Instrument对象引用，在沙箱中Instrument对象是一个非常重要的角色，它是沙箱访问和操作JVM的唯一通道，后续修改字节码和重定义类都要经过Instrument。另外，沙箱启动之后同时会启动一个内部的Jetty服务器，这个服务器用于外部进程和沙箱进行通信，上面看到的./sandbox.sh -p 33342 -d ‘my-sandbox-module/addLog’ 这行代码，实际上就是通过HTTP协议来告诉沙箱执行my-sanbox-module这个模块的addLog这个功能的。

4.2 无侵入

沙箱内部定义了一个Spy类，该类被称为“间谍类”，所有的沙箱模块功能都会通过这个间谍类驱动执行。下面给出一张示意图将业务代码、间谍类和模块代码串起来来帮助理解：

图4-2 沙箱无侵入核心实现

上图是沙箱AOP核心实现的伪代码，实际实现会比上图更复杂一些，沙箱内部通过修改和重定义业务类来实现上述功能的。在接口设计方面，沙箱通过事件驱动的方式，让模块开发者可以监听到方法执行的某个事件并设置回调逻辑，这一切都可以通过实现AdviceListener接口来做到，通过AdviceListener接口定义的行为，我们可以了解沙箱支持的监听事件如下：

4.3 隔离

JVM沙箱有自己的工作代码类，而这些代码类在沙箱被挂在到目标JVM之后，其涉及到的相关功能实现类都要被加载到目标JVM中，沙箱代码和业务代码共享JVM进程，这里有两个问题：1）如何避免沙箱代码和业务代码之间产生冲突；2）如何避免不同沙箱模块之间的代码产生冲突。为解决这两个问题，JVM SandBox定义了自己的类加载器，严格控制类的加载，沙箱的核心类加载器有两个：SandBoxClassLoader和ModuleJarClassLoader。SandBoxClassLoader用于加载沙箱自身的工作类，ModuleJarClassLoader用于加载三方自己开发的模块功能类，如上面的MySandBoxModule类。在沙箱中类加载器继承关系如下图所示：

图4-3 沙箱类加载器继承体系

通过类加载器，沙箱将沙箱代码和业务代码以及不同沙箱模块之间的代码隔离开来。

4.4 多租户

JVM沙箱提供的隔离机制也有两层含义，一层是沙箱容器和业务代码之间隔离以及沙箱内部模块之间隔离；另一层是不同用户的沙箱之间的隔离，这一层隔离用来支持多租户特性，也就是支持多个用户对同一个JVM同时使用沙箱功能且他们之间互不影响。沙箱的这种机制是通过支持创建多个SandBoxClassLoader的方式来实现的，每个SandBoxClassLoader关联唯一一个命名空间（namespace）用于标识不同的用户，示意图如下所示：

图4-4 多租户实现示意图

五、JVM Sandbox应用场景分析

JVM SandBox让动态无侵入地对业务代码进行AOP这个事情实现起来非常容易，但是这个事情做起来非常容易只是前提条件，更重要的是我们基于JVM SandBox能做什么？可以做的很多，比如：故障模拟、动态黑名单，动态日志、动态开关、系统流控、热修复，方法请求录制和结果回放、动态去依赖、依赖超时时间动态修改、甚至是修改JDK基础类的功能等等，当然不限于此，这里大家可以打开脑洞，天马行空地思考一下，下面再给出两个JVM SandBox应用场景的实现思路。

5.1 故障模拟

我们可以开发一个沙箱模块，通过和前台页面的交互，我们可以对任意业务类的任意方法注入故障来达到故障模拟的效果，用户交互示意图如下：

图5-1 故障模拟交互示意图

用户通过简单的界面操作即可完成故障注入，应用代码不需要提前埋点。

5.2 动态黑名单

我们还可以开发一个沙箱模块实现IP黑名单功能，针对指定IP的客户端，服务直接返回空结果，用户交互示意图如下：

图5-2 动态黑名单交互示意图

引用JVM SandBox官网的一句话：“JVM-SANDBOX还能帮助你做很多很多，取决于你的脑洞有多大了。”

总结

JVM SandBox是一种无侵入，可动态插拔，JVM层的AOP解决方案，基于JVM SandBox我们可以很容易地开发出很多有意思的工具，这完全归功于JVM SandBox为我们屏蔽了底层技术细节和实现复杂性。JVM SandBox很强大，这里需要感谢JVM SandBox的作者。除了无侵入，可动态插拔这两个优势之外，JVM SandBox在JVM层支持AOP这件事情本身就是一个绝对优势，因为我们开发的AOP能力不再依赖应用层所使用的容器，比如不管你使用的是Spring容器还是Plexus容器，不管你的Web容器是Tomcat还是Jetty、统统都没有关系。

回顾一下本文的内容：

回顾AOP技术；
介绍JVM SandBox是什么、来自哪里、怎么用；
通过Java Agent的加载介绍涉及到的JVM相关核心技术如：Attach机制、JVMTI、Instrument等；
介绍JVM SandBox的核心特性的设计与实现如：可插拔、无侵入、隔离、多租户；
介绍JVM SandBox可被应用的场景以及两个小例子。

参考文档

【1】http://developer.51cto.com/art/201803/568224.htm
【2】https://github.com/alibaba/jvm-sandbox
【3】https://www.jianshu.com/p/b72f66da679f

作者简介

陆晨，就职于美团点评，从事到店事业群业务后端研发工作，平时关注后端服务架构、领域驱动设计、海量运营等方面技术，个人对计算机基础技术兴趣较为浓厚，喜欢探究底层技术原理和同时关注技术应用价值。

创作场景

JVM SandBox 的技术原理与应用分析