之前在线上用的版本是fastjson-1.2.7.jar 一切正常,更换以后时间解析看似一切正常。
因为在系统中设计json反序列化的地方比较多,刚刚放到生产环境,app那边的接口报错了
java.lang.ClassFormatError: Invalid method Code length 66865 in class file com/alibaba/fastjson/serializer/ASMSerializer_6_UserKdlb at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at com.alibaba.fastjson.util.ASMClassLoader.defineClassPublic(ASMClassLoader.java:174) at com.alibaba.fastjson.serializer.ASMSerializerFactory.createJavaBeanSerializer(ASMSerializerFactory.java:396) at com.alibaba.fastjson.serializer.SerializeConfig.createASMSerializer(SerializeConfig.java:95) at com.alibaba.fastjson.serializer.SerializeConfig.createJavaBeanSerializer(SerializeConfig.java:163) at com.alibaba.fastjson.serializer.SerializeConfig.createJavaBeanSerializer(SerializeConfig.java:117) at com.alibaba.fastjson.serializer.SerializeConfig.getObjectWriter(SerializeConfig.java:504) at com.alibaba.fastjson.serializer.SerializeConfig.getObjectWriter(SerializeConfig.java:320) at com.alibaba.fastjson.JSON.toJSON(JSON.java:884) at com.alibaba.fastjson.JSON.toJSON(JSON.java:812) at com.alibaba.fastjson.JSON.toJSON(JSON.java:853) at com.alibaba.fastjson.JSON.toJSON(JSON.java:812) at com.alibaba.fastjson.JSON.toJSON(JSON.java:840) at com.alibaba.fastjson.JSON.toJSON(JSON.java:812) at com.alibaba.fastjson.JSON.toJSON(JSON.java:892) at com.alibaba.fastjson.JSON.toJSON(JSON.java:812) at com.netmarch.pointlocationapp.controller.AppPointLocationControllerNew.getList(AppPointLocationControllerNew.java:204) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221) at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136) at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110) at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:832) at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:743) at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:961) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:895) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:967) at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:869) at javax.servlet.http.HttpServlet.service(HttpServlet.java:648) at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:94) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:492) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:502) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1152) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1539) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1495) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
找到相应的方法,签名如下
@RequestMapping("/list") @ResponseBody public JSONObject getList(@RequestBody String body, UserKdlb userKdlb, Pager<UserKdlb> pagers, HttpServletRequest request, HttpServletResponse response) { AppUtils.setHeader(request, response); JSONObject obj = null; ReturnParam rp = new ReturnParam(); ... obj = (JSONObject) JSON.toJSON(rp); return obj; }
这是一直运行的代码,按常理来说如果有bug早就反应出来了。
codereview发现,这个json对象之前的步骤中插入一个list,相关代码如下
List<UserKdlb> list = null; public class UserKdlb implements Serializable{ private Byte pre_distribution_work_for_outsourcing_companies;//建设外包公司预分配工作 private String company_employees_must_complete_the_commissioning_time;//公司员工调试必须完成时间 //室外周报关联查询列表添加页面显示字段 private Integer number_of_points_entered_into_outdoor_construction_sites; //室外点位资料字表对应字段; private List<PointLocationFaultRecord> ltPLFR; //管理合同表查询此字段进而在页面显示样式,点位表f_htbh 存的可能是合同关联字段,也可能是项目关联字段,所以要查询两次; private String whxfxq; //关联点位子记录最新一条添加记录显示列 private String estimated_date_of_repair;//预计修复日期 private String dname;//同一故障点位名称 private String application_stop_instruction;//申请停用说明 private String son_estimated_date_of_repair;//子记录最新预计修复日期 private String son_application_stop_instruction;//子记录申请停用说明 //最新连接时间 private String ping_time; private int prediction_and_debugging_amount;//(预-调试完)总量 private int debugging_completion_difficulty;//调试完成难度 private int count;//项目数量 private int sum;//项目和 private int count_percent; private float total_commissioning_percent; private float debugging_completion_difficulty_percent; private float prediction_and_debugging_amount_percent; private float prediction_and_debugging_difficulty_percent; private Float projectPoints;//项目金额 private Integer projectCount;//项目个数
网上的说法是方法名太长,超过了65535(2^16-1,64K),里面有很多参数名比较长,可能在生成Getter/Setter时候过长,报错了。
由于记录这篇博文的时间比较仓促,笔者没有时间去深究java中方法(method)相关的结构信息,各位看官可以去了解一下
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.6
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.3
经过在网上一番搜索,说是非java编译生成的类,在运行时被进行检测,防止有恶意代码被注入。
Start-up time, I‘d say. Verification that classes are correct takes some time when the class is loaded. Since classes might be loaded in a lazy fashion (not on app start, but when being used for the first time), this might cause unexpected and undesired runtime delays.
Actually the class does not need to be checked in general. The compiler will not emit any invalid bytecode or class construct. The reason for verification is that the class may be build on one system, get hosted online and is transmitted to you through the unprotected internet. On this path, a malicious attacker might modify the bytecode and create something the compiler might never create; something that can crash the JVM or possibly circumvents security restrictions. Thus the class is verified before it is used. If this is a local application, there is usually no need to check the bytecode again.
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
选项。
按照以上方法给jvm加了参数 -noverify -XX:-UseSplitVerifier启动后并未凑效也没解决问题。
最终放弃添加jvm参数,按照官方的bug修复跟踪,替换成了1.2.13版本了,修复代码在167行,至此,线上正常接口运行了。
相关参考:
Ensuring JVM method size limit is never exceeded #661
Use of -noverify when launching java apps
原文地址:https://www.cnblogs.com/passedbylove/p/11044611.html