Java class被提前加载之深度历险记！-技术圈

你知道的越多，不知道的就越多，业余的像一棵小草！

你来，我们一起精进！你不来，我和你的竞争对手一起精进！

编辑：业余草

juejin.cn/post/7047014740693876744

1. 先说问题

我司搭建了一个类似于Skywalking的字节码插件平台。基本原理参考谈谈Java Intrumentation和相关应用^[1] 。所以我们就编写了各种神奇的插件。其中就有一个使用Sentinel限流MQ的插件。其核心逻辑就是，当用户空间有Sentinel相关类的时候，就使用Sentinel来做限流。

下面这个SentinelUtil类是用来判断是否有相关Sentinel

import com.alibaba.csp.sentinel.common.support.CircuitBreakerSupport;

public class SentinelUtil {
    private static boolean sentinelDisabled = true;

    static {
        try {
            //检测相关类和对应的方法是否存在
            final Class<?> circuitBreakerSupportClass = Class.forName("com.alibaba.csp.sentinel.common.support.CircuitBreakerSupport", false, SentinelUtil.class.getClassLoader());
            sentinelDisabled = false;
        } catch (Throwable throwable) {
        }
    }

    private SentinelUtil() {

    }

    public static boolean sentinelDisabled() {
        return sentinelDisabled;
    }
}

下面是MQ消费的逻辑：不存在Sentinel相关依赖就直接消费，存在的时候使用Sentinel限流消费

public abstract class BaseConcurrentMessageListener implements MessageListenerConcurrently {
 // ....
 @Override
    public ConsumeConcurrentlyStatus consumeMessage(final List<MessageExt> msgs, final ConsumeConcurrentlyContext context) {
        final MessageExt messageExt = msgs.get(0);

        // 不存在Sentinel相关依赖的时候就直接消费
  if (SentinelUtil.sentinelDisabled()) {
   return consumeInner(messageExt);
  }

  // 存在Sentinel相关类的时候就直接使用Sentinel来限流消费
  return CircuitBreakerSupport.syncExecute(resourceName, resourceType, origin,
   new CircuitBreakerCallback<ConsumeConcurrentlyStatus>() {
    @Override
    public ConsumeConcurrentlyStatus doWithCircuitBreaker() {
     // normal consumer logic
                    return consumeInner(messageExt);
    }
   },
   new CircuitBreakerFallback<ConsumeConcurrentlyStatus>() {
    @Override
    public ConsumeConcurrentlyStatus fallBack() {
     // fallBack logic 
    }
   });

    }
}

这里补充一下CircuitBreakerSupport用到的两个接口的定义

public interface CircuitBreakerCallback<T> {
    T doWithCircuitBreaker();
}

public interface CircuitBreakerFallback<T> {
    T fallBack();
}

此时，我们对Sentinel的依赖是provided级别。

<!-- 此依赖是我司对Sentinel的简单封装的jar包，用来简化Sentinel的使用 -->
    <dependency>
  <groupId>com.alibaba.csp</groupId>
  <artifactId>sentinel-common</artifactId>
  <scope>provided</scope>
</dependency>

所以上面的代码可以正常编译，但是运行期正常情况下会根据用户空间有没有scope=compile级别的该依赖来走不同的逻辑。

我们做完这个兼容判断后给自己的评价就是：完美。然后我们本地做了自测，测试了有Sentinel compile的依赖以及没有该依赖的场景，都没什么问题，完全在我们的意料之中。

但是，当我们把这个插件放开后真实地在开发环境跑的时候直接启动失败，抛出了一个java.lang.NoClassDefFoundError异常。

2. 初步分析

看到上面那个错误，我们初步分析如下：

用户应该是没有Sentinel的依赖的，不然不会找不到类
这个错误的原因肯定不是运行了BaseConcurrentMessageListener的consumeMessage方法导致的。因为如果是运行时发生的话，应该因为有了判断Sentinel是否存在的逻辑，所以不会走到CircuitBreakerSupport的syncExecute方法。而且，我们根本就没有发送消息，也就不会出发消费逻辑。

然后我们继续看异常栈，发现是这一行导致的异常：

我们找到那一行代码，如下：

public class DefaultRMQConsumer extends AbstractClientConfig {
 private DefaultMQPushConsumer createConsumer(...) throws MQClientException {
        //...
  
        // 就是这一行导致的错误
        baseConcurrentMessageListener = new NormalConcurrentMessageListener(nameServerAlias, subscribeTable);
  
  //...
    }
}

我们发现，这一行代码与我们代码发送唯一关联的就是NormalConcurrentMessageListener是BaseConcurrentMessageListener的子类。根据周志明大大总结的类加载的知识

「new」一个NormalConcurrentMessageListener确实会导致加载其父类BaseConcurrentMessageListener。但问题是：CircuitBreakerFallback只是BaseConcurrentMessageListener 类的一个方法中使用的类。按照周志明大大总结的类加载的知识，不应该是主动使用CircuitBreakerFallback的时候才会加载该类的吗？在没有主动使用的时候是不应该被加载的。

所以总结起来，按照我掌握的常规知识与现象来解释的话是自相矛盾的：

这个异常应该是主动使用该类的时候才会抛出，也就是实际运行BaseConcurrentMessageListener的consumeMessage方法才会抛出。
如果我们承认上面一个结论是正确的话，那么又会导致实际不会执行到CircuitBreakerFallback的方法，也就不会触发上面的异常。

好吧，我要崩溃了。。。

再用我简单的小脑袋瓜总结一下，现在我们有两个问题难以理解：

❝
为什么本地没有出现这个异常，到了开发环境就有了这个异常？
为什么方法中用到的类被提前加载了？
❞

3. 我的瞎想

根据上面的两个问题，我自然第一步就联想到了可能的原因：是不是JVM的锅？

❝
难道是JVM在Linux平台上的实现有bug，在windows（我本机是windows）和mac（其他同事用的mac也是一样的问题）上的实现没有bug？这个bug就是：某些情况下会导致类的提前加载。
❞

然后我就去JDK官方issue管理渠道（JBS - JDK Bug System：https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8279300?filter=allopenissues）搜索了ClassLoader相关的issue。

然后我就一个个翻阅了相关的issue。果然jdk还是靠谱的。

4. 我的猜想

在经过上面一轮「瞎想」之后，我开始反思这个过程可能的原因。然后我又去翻阅了周志明大大关于类加载方面的所有知识。果然，被我翻到了一点蛛丝马迹：

从这段话中，我们可以读出两点：

类加载的时机是不确定的，但是类初始化的时机是由JVM规范固定的那5种情况
类加载和类的初始化大部分情况下是同时发生的，但是少数情况还是有可能只发送类的加载，不发生类的初始化的

结合到我们这个场景下，实际上就是提前加载了类，但是估计没有初始化。

❝
那到底什么情况下会提前（这里的提前是指没有主动使用类）加载类，但是不发生类的初始化呢？
❞

5. 歪打正着

那既然遇到这个问题了，而且我们还不知道是啥原因的情况下，我们又该怎么解决呢？

我们再来分析下，其实像我们这种处理方式，在很多其他的框架中应该都有类似的方式。

❝
就判断有没有这个类，有的话就使用这个类提供的方法等。没有的话走兜底逻辑。这种兼容逻辑在开源框架中应该都有类似的解决方案。那为什么开源框架没有出现这种问题呢？
❞

肯定有某些条件限制住了该异常的发生。那到底是什么条件呢？

然后，我们就开始了尝试。既然找不到类，那我把找不到的那个类隐藏到另外一个类中是不是就可以了呢？

大体方案就是把限流逻辑隐藏到SentinelUtil中，然后调用SentinelUtil 的限流方法来做

public class SentinelUtil {
    private static boolean sentinelDisabled = true;

    static {
        try {
            //检测相关类和对应的方法是否存在
            final Class<?> circuitBreakerSupportClass = Class.forName("com.alibaba.csp.sentinel.common.support.CircuitBreakerSupport", false, SentinelUtil.class.getClassLoader());
            sentinelDisabled = false;
        } catch (Throwable throwable) {
        }
    }

    private SentinelUtil() {

    }

    public static boolean sentinelDisabled() {
        return sentinelDisabled;
    }
    
    /**
     * 把限流逻辑移到该方法中
     */
    public static <T> T supplySyncExecute(String resourceName, int resourceType, Supplier<T> circuitBreakerCallback, Supplier<T> fallback) {
       // 存在Sentinel相关类的时候就直接使用Sentinel来限流消费
  return CircuitBreakerSupport.syncExecute(resourceName, resourceType, origin,
   new CircuitBreakerCallback<ConsumeConcurrentlyStatus>() {
    @Override
    public ConsumeConcurrentlyStatus doWithCircuitBreaker() {
     // normal consumer logic
                                        return circuitBreakerCallback.get();
    }
   },
   new CircuitBreakerFallback<ConsumeConcurrentlyStatus>() {
    @Override
    public ConsumeConcurrentlyStatus fallBack() {
     return fallback.get(); 
    }
   });
    }
    
    private ConsumeConcurrentlyStatus consumeInne(...){
        //...消费逻辑
    }
}

消费监听器更改如下：

public abstract class BaseConcurrentMessageListener implements MessageListenerConcurrently {
 // ....
 @Override
    public ConsumeConcurrentlyStatus consumeMessage(final List<MessageExt> msgs, final ConsumeConcurrentlyContext context) {
        final MessageExt messageExt = msgs.get(0);

        // 不存在Sentinel相关依赖的时候就直接消费
  if (SentinelUtil.sentinelDisabled()) {
   return consumeInner(messageExt);
  }
  // 限流逻辑调用SentinelUtil的方法
                // 把限流逻辑以及
  return SentinelUtil.supplySyncExecute(...,
   new Supplier<ConsumeConcurrentlyStatus>() {
    @Override
    public ConsumeConcurrentlyStatus get() {
     // 消费逻辑
    }
   },
   new Supplier<ConsumeConcurrentlyStatus>() {
    @Override
    public ConsumeConcurrentlyStatus get() {
       // fall back逻辑
    }
   }
  );

    }
}

然后，下面就是见证奇迹的时刻了。我们在开发环境测试竟然没有那个神奇的异常了...

❝
所以，隐藏是有用的。我只要退后一步，JVM就不需要看到我了！！！
❞

6. 意外之喜

虽然，我们也不知道为啥就解决了上面的那个问题。但是心总是悬着的。因为在本地无法复现，只能在开发环境验证。那就是说，随时都有可能在本地无法复现，在其他环境有可能复现。那这种风险实际是挺大的。尤其如果没有经过开发和测试环境的验证就直接上生产环境的话，就可能直接嗝屁了。

所以，一直在搜索，却一直没有任何大佬给出相关的解释。

❝
然而，验证了一句话，叫做：再牛逼的难题，也抵不住傻逼似的坚持。
❞

终于在某乎上搜索到了我想要的答案：

关于Java class被提前加载的问题记录：https://zhuanlan.zhihu.com/p/417557986。

大家有兴趣可以看一下大佬的解答。这个博客不仅有实验代码，还有JVM规范内容。可以说是牛逼大发了，正是我想要的。

这篇文章总结起来，就以下几点：

❝
在一个类中存在这种涉及类型cast，即使是隐式的子类cast成父类的行为，就可能导致父类和子类被提前加载。
这种提前加载的行为是发生在校验字节码阶段
❞

7. 验证结论

我们按照上面博客的内容，自己做了对应的实验，确实如博客中所说的一样，在有类型转换的时候，会导致这种提前加载类的行为。

❝
那既然这种行为发生在字节码校验阶段，那是不是说我只要不校验字节码，这种提前加载的行为就不会发生呢？
❞

正好，JVM提供了相关的参数可以用来控制是否验证字节码

-Xverify:none  
// 或者 
-noverify

然后，我们就在开发环境中先使用我们第一版的代码（出现java.lang.NoClassDefFoundError异常的代码）跑了一下确实还是会抛出java.lang.NoClassDefFoundError异常。

然后，我们给JVM加上-noverify参数（或者-Xverify:none ）。神奇的事情发生了，没有异常了。意不意外，惊不惊喜。

8. 峰回路转

再回首一下我们之前的两个问题：

❝
为什么本地没有出现这个异常，到了开发环境就有了这个异常？
为什么方法中用到的类被提前加载了？
❞

现在第二个问题，其实我们已经有答案了：因为在调用CircuitBreakerSupport的syncExecute方法的时候需要接受一个CircuitBreakerCallback以及CircuitBreakerFallback接口类型的参数。又因为实际传入的是一这两个接口类型的匿名内部类，所以在加载BaseConcurrentMessageListener类的时候需要校验这种存在类型转换的情况，需要需要提前加载接口CircuitBreakerCallback以及CircuitBreakerFallback。所以发生了java.lang.NoClassDefFoundError异常。

并且，这种情况实际上在JVM规范中是有提到的：

链接如下：https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.1。

那既然如此，到底是为什么我们在本地没有出现这个异常呢？

允许你们停顿一下，思考研究个几分钟吧！

❝
1分钟 2分钟 n分钟。。。
❞

好吧，不卖关子了，直接说出我当时的想法吧。

❝
既然这个问题只要我们加上-noverify参数（或者-Xverify:none ）就不会出现该问题，那我们本地开发的时候是不是ide开发工具自动帮我们加上了这个参数了呢？
❞

然后，一启动，一看，世界都亮了。。。。

9. 一探到底

我自己又没有加上这个参数，那究竟是为啥ide要为我加上这样一个神奇的参数呢？然后我就百度了下，真被我找到原因了，竟然是因为这个：

好了，一切真相大白了。

❝
对于SpringBoot项目，【Enbale launch optimization】选项默认是勾选上的。这个选项会给JVM加上两个参数（其中一个就是-noverify参数）。然后我们的异常只会出现在字节码的验证阶段。由于-noverify参数关掉了字节码校验，所以本地是不会出现该异常的。
❞

10. 如何解决

上面，我们讨论了提前加载的原因（可能是一部分原因）。那我们编码的时候如果规避掉提前加载的问题呢？

退后一步：将需要校验的类放到另外一个类中（我们之前的解决方案就是这种方案）
尽量使用lamda表达式

对于第一种解决方案其实比较好理解，那第二种解决方案究竟是什么意思呢？

我们来看一下具体的代码（详细代码加我微信：xttblog2），下面就是最核心的测试代码：

package com.demo.load.lambda;

import com.alibaba.fastjson.serializer.JSONSerializer;
import com.alibaba.fastjson.serializer.ObjectSerializer;

import java.io.IOException;
import java.lang.reflect.Type;

public class InterfacesTest {
    public static void sayHello() {
        System.out.println("hello");
    }

    public static void testInterfaces(){
        InterfacesHolder holder = new InterfacesHolder();

        // 不会抛出异常
        // 原因：lambda表达式在编译期只会生成方法名类似于lambda$0的静态私有方法，不会生成对应接口实现类的class,对应class是在运行期生成
        //      所以在校验本类的字节码的时候是不需要校验类型的
        // 关于lambda表达式的实现原理参考：https://www.cnblogs.com/WJ5888/p/4667086.html
        //holder.invokeInterfaces((serializer, object, fieldName, fieldType, features) -> {
            // do nothing
        //});

        // 会抛出异常
        // 原因：匿名内部类在编译期就生成了对应接口的实现类，所以在校验本类字节码的时候会校验类型
        holder.invokeInterfaces(new ObjectSerializer() {
            @Override
            public void write(JSONSerializer serializer, Object object, Object fieldName, Type fieldType, int features) throws IOException {
                // do nothing
            }
        });
    }

    public static void main(String[] args) {
        InterfacesTest.sayHello();
    }

}

❝
你会发现，使用lamda时不会抛出异常的，但是使用匿名内部类是会抛出异常的。
❞

是不是已经智商不够用了呢？

下面我们简单分析下（太深入分析可能需要了解比较多的lamda表达式的实现原理）：

对于匿名内部类类，在编译期会生成一个对应的子类：

简单反编译

那实际上这个场景跟我们一开始遇到的场景是一样的。所以还是会抛异常。

那为什么使用lamda表达式就不会抛出异常呢？

首先，使用lamda表达式是不会在编译期生成对应接口的实现类或者父类的子类的：

其次，实际上lamda表达式也会生成实现类，但是是在运行期动态生成的。

所以，这样就比较好理解了，因为lamda表达式是在运行期生产的子类，所以在校验字节码的时候根本无法校验。但是匿名内部类在编译期就生产了子类，所以在字节码校验的时候就可以校验对应的子类了。

例子中，还有其他的几种情况会导致类的提前加载，这里简单总结一下：

存在类型转换的情况
catch块中使用异常的情况（这种情况我没有在JVM规范中找到对应的说明）

11. 总结一下

类的加载和类的初始化，大部分情况下是同时触发的，少数情况下只有类的加载，没有类的初始化
如果存在类型转换，可能会导致会导致提前加载接口或者父类。如果catch块中显示使用异常的情况，那么就会导致提前加载异常类。
在使用SpringBoot测试的时候，对于开发字节码植入逻辑的同学来说，一定要关掉【Enbale launch optimization】选项来测试。

Java class被提前加载之深度历险记！