JVM学习路径

背景知识

  • 我希望你必须具备下面的背景知识,再开始jvm的旅程
java相关
书单备注
java基础默认需要你有java背景相关知识,熟练掌握java常规语法
thinking in java没啥说的,必读
core java和thinking in java二选一吧不过这些java砖头书里面很多内容对互联网来说真没啥用
effective java没啥说的,必读
java concurrency in practice没啥说的,必读
  
周边知识
书单备注
计算机组成原理非特定,任意相关类型书籍
数据结构非特定,任意相关类型书籍
算法非特定,任意相关类型书籍
操作系统非特定,任意相关类型书籍对于java应用程序来说,jvm可以认为是一层操作系统 
设计模式非特定,任意相关类型书籍推荐gof,head first等比较经典的书籍
  

0.0 入门中的入门

书单备注
深入理解JVM,周志明入门中的入门,这本书里的东西都是最最基础的如果这本书能勾起你对JVM进一步的兴趣,继续
JVM规范必读,在学习阶段读个2-3遍都不过分JVM的原理和最终的解释都在这里
Java语言规范必读,在学习阶段读个2-3遍都不过分Java语言的原理和最终的解释都在这里注意:JVM和Java语言两个规范在细节中是不完全一致的,想想看为什么?
  

0.1 补充知识

  • 如果你还希望坚持,说明你对JVM抱有一定的兴趣。继续的学习需要更深入的背景知识
书单备注
虚拟机 – 系统与进程的通用平台https://book.douban.com/subject/3611865/了解虚拟机的定义和发展
编译原理https://book.douban.com/subject/3296317/对编译优化感兴趣的话,必读
C/C++语言知识大型JVM一般都使用C++编写有些小型JVM也能做到纯C编写,不容易(题外话:写惯了OO的代码,看到这种尽量模仿OO的过程式的代码,真心不习惯。另外在CSDN上看到有人开了一门课,叫做用C语言构建大规模OO系统,我也是服)
汇编语言知识所有JVM的底层都离不开汇编,需要了解
深入理解计算机系统https://book.douban.com/subject/26912767/对计算机系统有一个全面的认识
  

0.2 深入学习

书单备注
oracle/sun关于hotspot的在线文档很经典
Oracle JRockithttps://book.douban.com/subject/4873919/三大虚拟机中的另一个
IBM关于J9的在线文档三大虚拟机中的最后一个
R神领衔的国内JVM社区https://hllvm.group.iteye.com/这几年随着iteye的没落也没落了
R神自己关于JVM的帖子https://rednaxelafx.iteye.com/blog/362738比较杂,不建议新人阅读
R神自己推荐的书籍https://rednaxelafx.iteye.com/blog/1886170比我列的强太多太多了
Shenandoah设计原理https://wiki.openjdk.java.net/display/shenandoah/Main号称是下一代的GC,设计比较先进不过这两年的开发进度缓慢,和死了区别不大
Zing设计原理https://www.azul.com/products/zing/virtual-machine/设计先进的商用JVM,适用内存至少64G的大型堆内存空间
Gil Tene的JVM讲义https://greenteajug.cn/2015/10/18/understanding-java-garbage-collection/
dalvik/art设计原理作为客户端的jvm,dalvik/art和服务端的jvm在设计和理念上都有不小的区别在我这样的纯粹主义者看来dalvik/art甚至不应该被称为jvm(不符合jvm规范)不过在学习方面,dalvik/art为我们提供了一个很有意思的另样角度
垃圾回收算法手册https://book.douban.com/subject/26740958/对gc算法感兴趣的话,必读
google scholar的论文非常多,筛选是个头疼的问题
  

0.3 源码阅读

  • 我不太推荐在知识储备不丰富的时候直接阅读源码
书单备注
自己动手写Java虚拟机https://book.douban.com/subject/26802084/这本书真的挺好的,浅显易懂,省略了一些比较复杂的细节原书是使用Go语言写Java虚拟机。我自己写的时候使用的是Java,实现难度不大
jamvm非常精简的jamvm,全C语言编写,阅读难度不大(回忆杀:很怀念当年我用jamvm+gnu classpath在arm4/6上面跑java服务的岁月)
其它相关jvm网上开源的小型jvm还有很多,jikes,kvm都是不错的选择
hotspot源码我不太推荐直接读,除非有比较深刻的知识储备
  

0.9 入门结束

  • 到此为止,我可以认为你已经渡过了jvm的入门阶段了,这对于我来说已经是未知领域了,祝好运

Spring + Jackson有可能导致类数量爆炸

上周四线上的一个应用突然假死状态,通过gc log发现正在频繁的full gc,从gc log上可以看出是Metaspace导致频繁full gc(实际上这个时候Metaspace还没满,还有几十M的剩余),然后用jmap -histo <pid>发现有大量的GeneratedConstructorAccessorXXX和GeneratedMethodAccessorXXX类型的对象(总共有两万多个)。

熟悉java反射的同学应该知道,这两个类都是在反射过程中调用Method.invoke产生的,前者顾名思义就是调用构造函数产生的,后者就是调用普通的方法产生的,生成这个类的代码在:MethodAccessorGenerator

private static synchronized String generateName(boolean isConstructor,boolean forSerialization){if (isConstructor) {if (forSerialization) {int num = ++serializationConstructorSymnum;return "jdk/internal/reflect/GeneratedSerializationConstructorAccessor" + num;else {int num = ++constructorSymnum;return "jdk/internal/reflect/GeneratedConstructorAccessor" + num;}else {int num = ++methodSymnum;return "jdk/internal/reflect/GeneratedMethodAccessor" + num;}}

看到大量的这两个类,第一个念头是谁使用反射没有复用Method对象吧(意思是,我们如果使用反射的时候,如果这个反射会频繁的调用,那么不要每次都去拿Method,最好将method缓存着,不然成本会很高的)。有了这个念头后,我就想如果能把这个类代码dump下来,然后统计一下看看,是不是有些方法对应有很多的GeneratedMethodAccessor,那就基本上知道是什么方法的反射导致的了,然后翻翻代码基本上能确定原因。

正好github上有人写了个工具,可以将class的字节码dump出来:dumpclass

java -jar dumpclass.jar -p <pid> sun.reflect.GeneratedMethodAccessor*

这样就可以将所有的这样的类的字节码全部dump出来了,有类字节码然后我们使用javap对字节码进行反编译,然后就可以进行统计了。遗憾的是,最后发现几乎没有两个不同的GeneratedMethodAccessor类属于同一个方法反射生成的。线索到这里就断了,那说明不是因为没有缓存Method导致的,而是正常的反射使用。然后我随机的看了几个GeneratedMethodAccessor类的字节码,所有的方法基本上都是getter,那这说明什么呢?一般如果是业务代码里使用反射,大部分是调用一个业务方法,而什么会去调用getter呢?比如序列化,比如json。这个时候我正好看到这个应用里有很多地方打印日志,而打印日志的时候是直接使用Jackson将对象序列化之后打印,这里使用的Jackson序列化工具是公共包(common-api)里用Jackson封装的一个工具类。

然后我就怀疑是不是这个应用记录日志太多了,然后Jackson序列化的时候会反射调用对象的getter,然后产生大量的这个GeneratedMethodAccessor类呢?于是我就自己写了个简单的测试,我发现公共包的这个工具类并不会去调用Method.invoke,这就奇怪了,不是Jackson导致的?

不过正好这个时候,我在GeneratedMethodAccessor字节码里除了看到了getter,也看到了setter方法。有了setter方法,那说明应该不是打印日志导致的,打印日志只会序列化不会反序列化,线索再次中断。

然后我就从GeneratedMethodAccessor的字节码里找到一个类,然后查找引用,最后找到了Spring的Controller这一层。这个应用提供了非常非常多的HTTP API,然后这些Controller基本上都是返回对象的方式返回响应,并且Controller的参数接受的也是对象,类似下面这样的:

@RequestMapping(value = "/api/web/businessInfo/list/v2", method = RequestMethod.POST)@JsonResponseBody//返回BusinessInfoGridVO对象,接受BusinessInfoListVO对象public Pager<BusinessInfoGridVO> BusinessInfoListV2(@RequestBody BusinessInfoListVO infoListVO) {

我们都知道,返回对象的方式返回响应,在Spring框架里,会使用HttpMessageConverter进行序列化,然后将序列化结果吐给客户端,而接受对象也是在Spring框架里反序列化成对象。然后我找到了这个这个应用的HttpMessageConverter配置(实际上公司的web应用,如果引入了common-web, common-web-support,是不需要配置HttpMessageConverter的):

@Overridepublic void configureMessageConverters(List<HttpMessageConverter<?>> converters) {super.configureMessageConverters(converters);converters.add(new MappingJackson2HttpMessageConverter(JsonUtil.getObjectMapperInstance()));}

通过这里我们可以看到使用的是MappingJackson2HttpMessageConverter,而传入MappingJackson2HttpMessageConverter构造函数的是一个ObjectMapper:JsonUtil.getObjectMapperInstance()。这个JsonUtil是这个应用自己封装的一个json工具类(非来自common包),然后我就用这个工具类写个序列化测试,惊奇的发现产生了GeneratedMethodAccessor。看来是有什么配置导致公共包里的和这里的两个json工具类的差异。但是这个ObjectMapper的配置太多了,很难看出来是什么差异,而且我也对Jackson本身的机制不太熟悉,只好祭起了debug大法。

我先debug了一下公共包里的json工具类,发现这个类虽然不产生GeneratedMethodAccessor,但是会产生另外一个类:Xxx$Access4JacksonSerializer00000000,最前面的Xxx是你原来的类名。但是Jackson生成的机制和反射生成机制不同的是一个类只会产生一个这个类,而使用Java原生的反射是每个方法产生一个类。更恐怖的是,Java的反射给每个类都实例化一个单独Classloader(DelegatingClassLoader,而这也是导致Metaspace频繁full gc的其中一个原因,后文再说):

static Class<?> defineClass(String name, byte[] bytes, int off, int len,final ClassLoader parentClassLoader){ClassLoader newLoader = AccessController.doPrivileged(new PrivilegedAction<ClassLoader>() {public ClassLoader run() {return new DelegatingClassLoader(parentClassLoader);}});return unsafe.defineClass(name, bytes, off, len, newLoader, null);}

那么我们可以想象:假设我们有一万个getter+setter(对于大量的POJO来讲也不算多,也就总共5000个field)。

那为什么公共包里的JsonUtil不调用Method.invoke呢,经过debug找到了生成Xxx$Access4JacksonSerializer00000000的代码位置:PropertyAccessorCollector。然后设置断点,记录stacktrace,在每个stacktrack包含的方法都设置断点,然后再debug这个应用自己封装的JsonUtil类,发现这个JsonUtil没进入到这个路径,然后就打开两台电脑同时debug,看看是在哪里开始走不同的路径了,最终发现在这里com.fasterxml.jackson.databind.ser.BeanSerializerFactory:

// Need to allow reordering of properties to serializeif (_factoryConfig.hasSerializerModifiers()) {for (BeanSerializerModifier mod : _factoryConfig.serializerModifiers()) {props = mod.orderProperties(config, beanDesc, props);}}

这就很明显了,_factoryConfig.hasSerializerModifiers()看起来是配置的东西导致的。曙光来了,后来发现是这个是下面这个配置导致hasSerializerModifiers为true,在公共包的json工具类里是有这个配置的,而这个JsonUtil是没有配置的。

objectMapper.registerModules(new AfterburnerModule())

现在问题基本上确定了,也就是Spring使用的Jackson序列化导致的,只需要改一下配置基本上就没有问题了(AfterburnerModule github)。

但是在查这个问题的时候,还有另外一个问题:其实频繁发生full gc的时候,Metaspace并没有满。那么没有满为啥就频繁full gc呢,其实Metaspace的内存分配是按照classloader分配的,也就是会给每个classloader分配一块内存,所以如果存在大量的classloader的话,会有很严重的碎片问题,碎片多了自然没有满就会full gc了。

后记

1. 经常看到各种项目里有JsonUtil, HttpUtil,DateUtil, StringUtil等等各种Util,强烈不建议这样做,一来是没有什么必要,二来也让后来的人产生困惑,三来如果有bug什么的公共包里可以集中修复,另外公共包里的类也经过了更充分的测试。

2. 很多应用里打印了大量的日志,主要是担心查问题的时候没有线索,但是直接将对象序列化的方式打印日志并不可取,首先是这样打印的日志太多太多了,完全没有必要,消耗资源不说,还有可能泄露一些敏感信息。那么即使要将对象完全打印出来,最好也是通过覆盖toString的方法来输出日志,使用lombok等工具覆盖toString方法也几乎没有什么成本。

3. HttpMessageConverter这个配置公共包里已经配置好了,不需要自己再定义

注:转载自公司内wiki

常用的http状态码

一些常见的状态码为:
200 – 服务器成功返回网页 404 – 请求的网页不存在 503 – 服务不可用
1xx(临时响应)
表示临时响应并需要请求者继续执行操作的状态代码。

代码   说明
100   (继续) 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分,正在等待其余部分。 
101   (切换协议) 请求者已要求服务器切换协议,服务器已确认并准备切换。

2xx (成功)
表示成功处理了请求的状态代码。

代码   说明
200   (成功)  服务器已成功处理了请求。 通常,这表示服务器提供了请求的网页。
201   (已创建)  请求成功并且服务器创建了新的资源。
202   (已接受)  服务器已接受请求,但尚未处理。
203   (非授权信息)  服务器已成功处理了请求,但返回的信息可能来自另一来源。
204   (无内容)  服务器成功处理了请求,但没有返回任何内容。
205   (重置内容) 服务器成功处理了请求,但没有返回任何内容。
206   (部分内容)  服务器成功处理了部分 GET 请求。

3xx (重定向)
表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向。

代码   说明
300   (多种选择)  针对请求,服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择。
301   (永久移动)  请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。
302   (临时移动)  服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
303   (查看其他位置) 请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码。
304   (未修改) 自从上次请求后,请求的网页未修改过。 服务器返回此响应时,不会返回网页内容。
305   (使用代理) 请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理。
307   (临时重定向)  服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。

4xx(请求错误)
这些状态代码表示请求可能出错,妨碍了服务器的处理。

代码   说明
400   (错误请求) 服务器不理解请求的语法。
401   (未授权) 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
403   (禁止) 服务器拒绝请求。
404   (未找到) 服务器找不到请求的网页。
405   (方法禁用) 禁用请求中指定的方法。
406   (不接受) 无法使用请求的内容特性响应请求的网页。
407   (需要代理授权) 此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理。
408   (请求超时)  服务器等候请求时发生超时。
409   (冲突)  服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410   (已删除)  如果请求的资源已永久删除,服务器就会返回此响应。
411   (需要有效长度) 服务器不接受不含有效内容长度标头字段的请求。
412   (未满足前提条件) 服务器未满足请求者在请求中设置的其中一个前提条件。
413   (请求实体过大) 服务器无法处理请求,因为请求实体过大,超出服务器的处理能力。
414   (请求的 URI 过长) 请求的 URI(通常为网址)过长,服务器无法处理。
415   (不支持的媒体类型) 请求的格式不受请求页面的支持。
416   (请求范围不符合要求) 如果页面无法提供请求的范围,则服务器会返回此状态代码。
417   (未满足期望值) 服务器未满足”期望”请求标头字段的要求。

5xx(服务器错误)
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误,而不是请求出错。

代码   说明
500   (服务器内部错误)  服务器遇到错误,无法完成请求。
501   (尚未实施) 服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码。
502   (错误网关) 服务器作为网关或代理,从上游服务器收到无效响应。
503   (服务不可用) 服务器目前无法使用(由于超载或停机维护)。 通常,这只是暂时状态。
504   (网关超时)  服务器作为网关或代理,但是没有及时从上游服务器收到请求。
505   (HTTP 版本不受支持) 服务器不支持请求中所用的 HTTP 协议版本。

RFC 6585 最近刚刚发布,该文档描述了 4 个新的 HTTP 状态码。

HTTP 协议还在变化?是的,HTTP 协议一直在演变,新的状态码对于开发 REST 服务或者说是基于 HTTP 的服务非常有用,下面我们为你详细介绍这四个新的状态码以及是否应该使用。

428 Precondition Required (要求先决条件)

先决条件是客户端发送 HTTP 请求时,如果想要请求能成功必须满足一些预设的条件。

一个好的例子就是 If-None-Match 头,经常在 GET 请求中使用,如果指定了 If-None-Match ,那么客户端只在响应中的 ETag 改变后才会重新接收回应。

先决条件的另外一个例子就是 If-Match 头,这个一般用在 PUT 请求上用于指示只更新没被改变的资源,这在多个客户端使用 HTTP 服务时用来防止彼此间不会覆盖相同内容。

当服务器端使用 428 Precondition Required 状态码时,表示客户端必须发送上述的请求头才能执行请求,这个方法为服务器提供一种有效的方法来阻止 ‘lost update’ 问题。

429 Too Many Requests (太多请求)

当你需要限制客户端请求某个服务数量时,该状态码就很有用,也就是请求速度限制。

在此之前,有一些类似的状态码,例如 ‘509 Bandwidth Limit Exceeded’. Twitter 使用 420 (这不是HTTP定义的状态码)

如果你希望限制客户端对服务的请求数,可使用 429 状态码,同时包含一个 Retry-After 响应头用于告诉客户端多长时间后可以再次请求服务。

431 Request Header Fields Too Large (请求头字段太大)

某些情况下,客户端发送 HTTP 请求头会变得很大,那么服务器可发送 431 Request Header Fields Too Large 来指明该问题。

我不太清楚为什么没有 430 状态码,而是直接从 429 跳到 431,我尝试搜索但没有结果。唯一的猜测是 430 Forbidden 跟 403 Forbidden 太像了,为了避免混淆才这么做的,天知道!

511 Network Authentication Required (要求网络认证)

对我来说这个状态码很有趣,如果你在开发一个 HTTP 服务器,你不一定需要处理该状态码,但如果你在编写 HTTP 客户端,那这个状态码就非常重要。

如果你频繁使用笔记本和智能手机,你可能会注意到大量的公用 WIFI 服务要求你必须接受一些协议或者必须登录后才能使用。

这是通过拦截HTTP流量,当用户试图访问网络返回一个重定向和登录,这很讨厌,但是实际情况就是这样的。

使用这些“拦截”客户端,会有一些讨厌的副作用。在 RFC 中有提到这两个的例子:

  • 如果你在登录WIFI前访问某个网站,网络设备将会拦截首个请求,这些设备往往也有自己的网站图标 ‘favicon.ico’。登录后您会发现,有一段时间内你访问的网站图标一直是WIFI登录网站的图标。
  • 如果客户端使用HTTP请求来查找文档(可能是JSON),网络将会响应一个登录页,这样你的客户端就会解析错误并导致客户端运行异常,在现实中这种问题非常常见。

因此 511 状态码的提出就是为了解决这个问题。

如果你正在编写 HTTP 的客户端,你最好还是检查 511 状态码以确认是否需要认证后才能访问。

100Continue继续。客户端应继续其请求
101Switching Protocols切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议
200OK请求成功。一般用于GET与POST请求
201Created已创建。成功请求并创建了新的资源
202Accepted已接受。已经接受请求,但未处理完成
203Non-Authoritative Information非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本
204No Content无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档
205Reset Content重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域
206Partial Content部分内容。服务器成功处理了部分GET请求
300Multiple Choices多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择
301Moved Permanently永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302Found临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303See Other查看其它地址。与301类似。使用GET和POST请求查看
304Not Modified未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305Use Proxy使用代理。所请求的资源必须通过代理访问
306Unused已经被废弃的HTTP状态码
307Temporary Redirect临时重定向。与302类似。使用GET请求重定向
400Bad Request客户端请求的语法错误,服务器无法理解
401Unauthorized请求要求用户的身份认证
402Payment Required保留,将来使用
403Forbidden服务器理解请求客户端的请求,但是拒绝执行此请求
404Not Found服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置”您所请求的资源无法找到”的个性页面
405Method Not Allowed客户端请求中的方法被禁止
406Not Acceptable服务器无法根据客户端请求的内容特性完成请求
407Proxy Authentication Required请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权
408Request Time-out服务器等待客户端发送的请求时间过长,超时
409Conflict服务器完成客户端的 PUT 请求时可能返回此代码,服务器处理请求时发生了冲突
410Gone客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置
411Length Required服务器无法处理客户端发送的不带Content-Length的请求信息
412Precondition Failed客户端请求信息的先决条件错误
413Request Entity Too Large由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息
414Request-URI Too Large请求的URI过长(URI通常为网址),服务器无法处理
415Unsupported Media Type服务器无法处理请求附带的媒体格式
416Requested range not satisfiable客户端请求的范围无效
417Expectation Failed服务器无法满足Expect的请求头信息
500Internal Server Error服务器内部错误,无法完成请求
501Not Implemented服务器不支持请求的功能,无法完成请求
502Bad Gateway作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应
503Service Unavailable由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504Gateway Time-out充当网关或代理的服务器,未及时从远端服务器获取请求
505HTTP Version not supported服务器不支持请求的HTTP协议的版本,无法完成处理