JVM的noverify选项

最近在CI上运行测试代码的时候遇到一个java.lang.VerifyError错误。

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.129 sec <<< FAILURE! - in com.example.CustomerTest
runTest(com.example.CustomerTest)  Time elapsed: 0.009 sec  <<< ERROR!
java.lang.VerifyError: (class: au/com/dius/pact/consumer/PactProviderRule, method: findPactVerification, signature: (Lau/com/dius/pact/consumer/PactVerifications;)Ljava/util/Optional;, offset: 12) Illegal type 262144 in constant pool
    at com.example.CustomerTest.<init>(CustomerTest.java:32)

JVM加载class文件时会做字节码校验(bytecode verification)。这篇文档非常详细地讲了JVM会做哪些校验。 如果你的class文件是由java源文件通过javac编译出来的,那么基本上不用担心bytecode verification。 如果class文件是由asm、cglib等动态生成出来的或者由其它编译器生成的,那么JVM在校验它的bytecode时就有可能失败。 失败的原因可能是你生成的bytecode有bug,也可能是由于新版本的JVM加入了新的验证条件后导致原来可以通过验证的bytecode现在不能通过了。

很多Java框架都会动态生成class文件,再加上JVM版本也会时不时地修改它的bytecode verification行为。 所以,运行代码时偶尔会遇到java.lang.VerifyError错误。 在不能修改框架代码或者切换JVM实现的情况下,JVM提供了一些选项可以让你改变或者绕过bytecode verification。

-XX:-UseSplitVerifier

-XX:-UseSplitVerifier可以让JVM不开启“type-checking verifier”。 这样就不强制要求class文件含有StackMapTable(所有Java 7 version 51之后的class文件默认要求含有StackMapTable)。

-noverify

-noverify选项可以关闭bytecode verification。

有的观点认为某些bytecode verification除了给动态生成bytecode增加麻烦之外,并没有什么大用。 但是这篇文章强烈建议不要关闭bytecode verification,特别是在生产环境里。 因为bytecode verification可以检测到恶意代码或者代码中的bug。 特别是代码中的bug,因为没有人可以保证(动态产生的)字节码是百分百bug free的。

回到我的问题,由于PactProviderRule类来自于外部依赖,CI上的JVM也不能替换 (CI上用的是非oracle的JVM实现,该测试代码在本地的官方JVM上是可以运行通过,所以CI上的失败有一定可能是其用的JVM实现的原因), 所以一个简单的方法是在maven跑测试代码时,给JVM加上-noverify选项。

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
      <argLine>-noverify</argLine>
    </configuration>
  </plugin>

更多的参考文档:

2016-07-04 08:36
推荐到豆瓣

如果你觉得这篇文章对你有用,可以微信扫一扫表示🙏 / If you find this post is useful to you, buy me 🍶 via Wechat