排列三彩票网博彩平台爱好者

 火博体育[[339593]]火博体育

引子

纪录一次线上JVM堆外内存泄漏问题的排查过程与念念路，其中夹带一些「JVM内存分拨的旨趣分析」以及「常用的JVM问题排查技巧和器用共享」，但愿对全球有所匡助。

在通盘排查过程中，我也走了不少弯路，关联词在著述中我仍然会把齐全的念念路和想法写出来，作为念一次资格警戒，给后东说念主参考，著述终末也总结了下内存泄漏问题快速排查的几个原则。

「本文的主要内容：」

故障刻画和排查过程 故障原因和贬责决议分析 JVM堆内内存和堆外内存分拨旨趣 常用的程度内存泄漏排查领导和器用先容和使用

故障刻画

8月12日中午午休时辰，咱们生意职业收到告警，职业程度占用容器的物理内存(16G)起头了80%的阈值，况且还在胁制上升。

 

监控系统调出图表稽查：

 

像是Java程度发生了内存泄漏，而咱们堆内存的适度是4G，这种大于4G将近吃满内存应该是JVM堆外内存泄漏。

阐明了下其时职业程度的启动建立：

-Xms4g -Xmx4g -Xmn2g -Xss1024K -XX:PermSize=256m -XX:MaxPermSize=512m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=80 

天然本日莫得上线新代码，关联词「本日上昼咱们正在使用音讯部队推送历史数据的建造剧本，该任务会多半调用咱们职业其中的某一个接口」，是以初步怀疑和该接口关联。

下图是该调用接口本日的探员量变化：

 

不错看到案发其时调用量比拟平常情况(每分钟200+次)升迁了许多(每分钟5000+次)。

排列三彩票网

「咱们暂时让剧本罢手发送音讯，该接口调用量下落到每分钟200+次，容器内存不再以极高斜率上升，一切似乎收复了平常。」

接下来排查这个接口是不是发生了内存泄漏。

排查过程

起头咱们先归来下Java程度的内存分拨，便捷咱们底下排查念念路的施展。

「以咱们线上使用的JDK1.8版块为例」。JVM内存分拨网上有许多总结，我就不再进行二次创作。

JVM内存区域的分别为两块：堆区和非堆区。

堆区：即是咱们熟知的重生代老年代。 非堆区：非堆区如图中所示，有元数据区和班师内存。

 

「这里需要独特能干的是：遥远代(JDK8的原生去)存放JVM运行时使用的类，遥远代的对象在full GC时进行垃圾收罗。」

温习结束JVM的内存分拨，让咱们回到故障上来。

堆内存分析

虽说一运行就基本阐明与堆内存无关，因为透露的内存占用起头了堆内存适度4G，关联词咱们为了保障起见先看下堆内存有什么萍踪。

咱们不雅察了重生代和老年代内存占用弧线以及回收次数统计，和往常一样莫得大问题，咱们接着在事故现场的容器上dump了一份JVM堆内存的日记。

博彩平台爱好者

堆内存Dump

www.betroyalclub.com

堆内存快照dump号令：

jmap -dump:live,format=b,file=xxxx.hprof pid 

画外音：你也不错使用jmap -histo:live pid班师稽查堆内存存活的对象。

导出后，将Dump文献下载回腹地，然后不错使用Eclipse的MAT(Memory Analyzer)或者JDK自带的JVisualVM怒放日记文献。

使用MAT怒放文献如图所示：

 

「不错看到堆内存中，有一些nio关联的大对象，比如正在采取音讯部队音讯的nioChannel，还有nio.HeapByteBuffer，关联词数目未几，不可作为判断的依据，先放着不雅察下。」

下一步，我运行浏览该接口代码，接口里面主要逻辑是调用集团的WCS客户端，将数据库表中数据查表后写入WCS，莫得其他独特逻辑

发觉莫得什么特殊逻辑后，我运行怀疑WCS客户端封装是否存在内存泄漏，这样怀疑的意义是，WCS客户端底层是由SCF客户端封装的，作为RPC框架，其底层通信传输契约有可能会央求班师内存。

「是不是我的代码起程了WCS客户端的Bug，导致胁制地央求班师内存的调用，最终吃满内存。」

我谈判上了WCS的值班东说念主，将咱们遭受的问题和他们刻画了一下，他们回答咱们，会在他们腹地实行下写入操作的压测，望望能不可复现咱们的问题。

既然恭候他们的响应还需要时辰，咱们就准备先我方琢磨下原因。

「我将怀疑的视力停留在了班师内存上，怀疑是由于接口调用量过大，客户端对nio使用欠妥，导致使用ByteBuffer央求过多的班师内存。」

「画外音：最终的效力诠释，这一个先入之见的念念路导致排查过程走了弯路。在问题的排查过程中，用合理的估量来消弱排查限度是不错的，但最佳先把每种可能性齐列了了，在发现我方深切某个可能性无果时，要实时回头仔细凝视其他可能性。」

沙箱环境复现

为了能还原其时的故障场景，我在沙箱环境央求了一台压测机器，来确保和线上环境一致。

「起头咱们先模拟内存溢出的情况(多半调用接口)：」

咱们让剧本赓续推送数据，调用咱们的接口，咱们络续不雅察内存占用。

当运行调用后，内存便运行络续增长，况且看起来莫得被适度住(莫得因为适度触发Full GC)。

 

「接着咱们来模拟下平时平常调用量的情况(平常量调用接口)：」

咱们将该接口平时平常的调用量(比较小，且每10分钟进行一次批量调用)切到该压测机器上，取得了下图这样的须生代内存和物理内存趋势：

 

「问题来了：为何内存会胁制往上走吃满内存呢?」

其时估量是由于JVM程度并莫得关于班师内存大小进行适度(-XX:MaxDirectMemorySize)，是以堆外内存胁制高潮，并不会触发FullGC操作。

「上图好像得出两个论断：」

在内存透露的接口调用量很大的时候，淌若碰巧堆内须生代等其他情况一直不称心FullGC条目，就一直不会FullGC，班师内存一齐高潮。 而在平时低调用量的情况下， 内存泄漏的比较慢，FullGC总会到来，回收掉透露的那部分，这亦然平时莫得出问题，平常运行了很久的原因。

「由于上头提到，咱们程度的启动参数中并莫得适度班师内存，于是咱们将-XX:MaxDirectMemorySize建立加上，再次在沙箱环境进行了检会。」

效力发现，程度占用的物理内存依然会胁制高潮，超出了咱们成立的适度，“看上去”建立似乎没起作用。

皇冠客服飞机：@seo3687

这让我很惊诧，难说念JVM对内存的适度出现了问题?

「到了这里，好像看出我排查过程中念念路执着于班师内存的透露，触景伤情了。」

「画外音：咱们应该敬佩JVM对内存的掌抓，淌若发现参数失效，多从我方身上找原因，望望是不是我方使用参数有误。」

班师内存分析

欧博娱乐城欧

为了更进一步的探员了了班师内存里有什么，我运行对班师内存下手。由于班师内存并不可像堆内存一样，很容易的看出通盘占用的对象，咱们需要一些号令来对班师内存进行排查，我灵验了几种成见，来稽查班师内存里到底出现了什么问题。

稽查程度内存信息 pmap

pmap - report memory map of a process(稽查程度的内存映像信息)

pmap号令用于论说程度的内存映射关系，是Linux调试及运维一个很好的器用。

pmap -x pid 淌若需要排序  | sort -n -k3** 

实行后我取得了底下的输出，删减输出如下:

.. 00007fa2d4000000    8660    8660    8660 rw---   [ anon ] 00007fa65f12a000    8664    8664    8664 rw---   [ anon ] 00007fa610000000    9840    9832    9832 rw---   [ anon ] 00007fa5f75ff000   10244   10244   10244 rw---   [ anon ] 00007fa6005fe000   59400   10276   10276 rw---   [ anon ] 00007fa3f8000000   10468   10468   10468 rw---   [ anon ] 00007fa60c000000   10480   10480   10480 rw---   [ anon ] 00007fa614000000   10724   10696   10696 rw---   [ anon ] 00007fa6e1c59000   13048   11228       0 r-x-- libjvm.so 00007fa604000000   12140   12016   12016 rw---   [ anon ] 00007fa654000000   13316   13096   13096 rw---   [ anon ] 00007fa618000000   16888   16748   16748 rw---   [ anon ] 00007fa624000000   37504   18756   18756 rw---   [ anon ] 00007fa62c000000   53220   22368   22368 rw---   [ anon ] 00007fa630000000   25128   23648   23648 rw---   [ anon ] 00007fa63c000000   28044   24300   24300 rw---   [ anon ] 00007fa61c000000   42376   27348   27348 rw---   [ anon ] 00007fa628000000   29692   27388   27388 rw---   [ anon ] 00007fa640000000   28016   28016   28016 rw---   [ anon ] 00007fa620000000   28228   28216   28216 rw---   [ anon ] 00007fa634000000   36096   30024   30024 rw---   [ anon ] 00007fa638000000   65516   40128   40128 rw---   [ anon ] 00007fa478000000   46280   46240   46240 rw---   [ anon ] 0000000000f7e000   47980   47856   47856 rw---   [ anon ] 00007fa67ccf0000   52288   51264   51264 rw---   [ anon ] 00007fa6dc000000   65512   63264   63264 rw---   [ anon ] 00007fa6cd000000   71296   68916   68916 rwx--   [ anon ] 00000006c0000000 4359360 2735484 2735484 rw---   [ anon ] 

不错看出，最底下一瞥是堆内存的映射，占用4G，其他上头有越过多小的内存占用，不外通过这些信息咱们依然看不出问题。

堆外内存追踪 NativeMemoryTracking

Native Memory Tracking (NMT) 是Hotspot VM用来分析VM里面内存使用情况的一个功能。咱们不错诓骗jcmd(jdk自带)这个器用来探员NMT的数据。

唯美

NMT必须先通过VM启动参数中怒放，不外要能干的是，怒放NMT会带来5%-10%的性能损耗。

-XX:NativeMemoryTracking=[off | summary | detail] # off: 默许关闭 # summary: 只统计各个分类的内存使用情况. # detail: Collect memory usage by individual call sites. 

然后运行程度，不错使用底下的号令稽查班师内存：

jcmd <pid> VM.native_memory [summary | detail | baseline | summary.diff | detail.diff | shutdown] [scale= KB | MB | GB]   # summary: 分类内存使用情况. # detail: 详备内存使用情况，除了summary信息除外还包含了诬捏内存使用情况。 # baseline: 创建内存使用快照，便捷和背面作念对比 # summary.diff: 和上一次baseline的summary对比 # detail.diff: 和上一次baseline的detail对比 # shutdown: 关闭NMT 

咱们使用：

jcmd pid VM.native_memory detail scale=MB > temp.txt 

取得如图效力：

 

上图中给咱们的信息，齐不可很显著的看出问题，至少我其时依然不可通过这几次信息看出问题。

排查似乎堕入了僵局。

山重水复疑无路

在排查堕入停滞的时候，咱们取得了来自WCS和SCF方面的回答，「两方齐笃定了他们的封装莫得内存泄漏的存在」，WCS方面莫得使用班师内存，而SCF天然作为底层RPC契约，关联词也不会留传这样显著的内存bug，否则应该线上有许多响应。

稽查JVM内存信息 jmap

此时，找不到问题的我再次新开了一个沙箱容器，运行职业程度，然后运行jmap号令，看一看JVM内存的「内容建立」：

jmap -heap pid 

取得效力：

Attaching to process ID 1474, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.66-b17  using parallel threads in the new generation. using thread-local object allocation. Concurrent Mark-Sweep GC  Heap Configuration:    MinHeapFreeRatio         = 40    MaxHeapFreeRatio         = 70    MaxHeapSize              = 4294967296 (4096.0MB)    NewSize                  = 2147483648 (2048.0MB)    MaxNewSize               = 2147483648 (2048.0MB)    OldSize                  = 2147483648 (2048.0MB)    NewRatio                 = 2    SurvivorRatio            = 8    MetaspaceSize            = 21807104 (20.796875MB)    CompressedClassSpaceSize = 1073741824 (1024.0MB)    MaxMetaspaceSize         = 17592186044415 MB    G1HeapRegionSize         = 0 (0.0MB)  Heap Usage: New Generation (Eden + 1 Survivor Space):    capacity = 1932787712 (1843.25MB)    used     = 1698208480 (1619.5378112792969MB)    free     = 234579232 (223.71218872070312MB)    87.86316621615607% used Eden Space:    capacity = 1718091776 (1638.5MB)    used     = 1690833680 (1612.504653930664MB)    free     = 27258096 (25.995346069335938MB)    98.41346682518548% used From Space:    capacity = 214695936 (204.75MB)    used     = 7374800 (7.0331573486328125MB)    free     = 207321136 (197.7168426513672MB)    3.4349974840697497% used To Space:    capacity = 214695936 (204.75MB)    used     = 0 (0.0MB)    free     = 214695936 (204.75MB)    0.0% used concurrent mark-sweep generation:    capacity = 2147483648 (2048.0MB)    used     = 322602776 (307.6579818725586MB)    free     = 1824880872 (1740.3420181274414MB)    15.022362396121025% used  29425 interned Strings occupying 3202824 bytes 

输出的信息中，看得出老年代和重生代齐蛮平常的，元空间也只占用了20M，班师内存看起来亦然2g...

嗯?为什么MaxMetaspaceSize = 17592186044415 MB?「看起来就和没适度一样」。

再仔细望望咱们的启动参数：

-Xms4g -Xmx4g -Xmn2g -Xss1024K -XX:PermSize=256m -XX:MaxPermSize=512m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=80 

建立的是-XX:PermSize=256m -XX:MaxPermSize=512m，也即是遥远代的内存空间。「而1.8后，Hotspot诬捏机仍是移除了遥远代，使用了元空间代替。」 由于咱们线上使用的是JDK1.8，「是以咱们关于元空间的最大容量根蒂就莫得作念适度」，-XX:PermSize=256m -XX:MaxPermSize=512m 这两个参数关于1.8即是过时的参数。

底下的图刻画了从1.7到1.8，遥远代的变更：

 

「那会不会是元空间内存透露了呢?」

我取舍了在腹地进行测试，便捷鼎新参数，也便捷使用JVisualVM器用直不雅的看出内存变化。

使用JVisualVM不雅察程度运行

起头适度住元空间，使用参数-XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=128m，然后在腹地轮回调用出问题的接口。

取得如图：

大乐透第23056期-第23065期前区奖号冷温热分布统计：

前区012路：上期前区012路比为1：2：2，012路号码走势基本平衡，最近10期前区012路奖号个数比为16：20：14，1路号码表现较热。本期预计前区012路号码走势基本持平，推荐012路比2：1：2。

 

「不错看出，在元空间花费时，系统起程了Full GC，元空间内存取得回收，况且卸载了许多类。」

然后咱们将元空间适度去掉，也即是使用之前出问题的参数：

-Xms4g -Xmx4g -Xmn2g -Xss1024K -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=80 -XX:MaxDirectMemorySize=2g -XX:+UnlockDiagnosticVMOptions 

取得如图：

 

「不错看出，元空间在胁制高潮，况且已装入的类跟着调用量的加多也在胁制高潮，呈现正关联趋势。」

柳暗花明又一村

问题一下子轩敞了起来，「跟着每次接口的调用，极有可能是某个类齐在胁制的被创建，占用了元空间的内存」。

某明星前锋XXX因赌球被停赛三个月，他在多场比赛中下注并获得了高额的收益，但却因此失去了参加2023年欧洲杯的机会，引发了粉丝们的强烈不满。

不雅察JVM类加载情况 -verbose

在调试法子时，偶然需要稽查法子加载的类、内存回收情况、调用的腹地接口等。这时候就需要-verbose号令。在myeclipse不错通过右键成立(如下)，也不错在号令行输入java -verbose来稽查。

-verbose:class 稽查类加载情况 -verbose:gc 稽查诬捏机中内存回收情况 -verbose:jni 稽查腹地步伐调用的情况 

咱们在腹地环境，添加启动参数-verbose:class轮回调用接口。

不错看到生成了无数com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto:

皇冠hg86a

[Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar] [Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar] [Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar] [Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar] [Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar] [Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar] 

当调用了许屡次，集会了一定的类时，咱们手动实行Full GC，进行类加载器的回收，咱们发现多半的fastjson关联类被回收。

「淌若在回收前，使用jmap稽查类加载情况，相同也不错发现多半的fastjson关联类：」

jmap -clstats 7984 

 

这下有了成见，「此次仔细排查代码」，稽查代码逻辑里那处用到了fastjson，发现了如下代码：

/**  * 复返Json字符串.驼峰转_  * @param bean 实体类.  */ public static String buildData(Object bean) {     try {         SerializeConfig CONFIG = new SerializeConfig();         CONFIG.propertyNamingStrategy = PropertyNamingStrategy.SnakeCase;         return jsonString = JSON.toJSONString(bean, CONFIG);     } catch (Exception e) {         return null;     } } 

问题根因

咱们在调用wcs前将驼峰字段的实体类序列化成下划线字段，**这需要使用fastjson的SerializeConfig，而咱们在静态步伐中对其进行了实例化。SerializeConfig创建时默许会创建一个ASM代理类用来收场对缠绵对象的序列化。也即是上头被庸碌创建的类com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto,淌若咱们复用SerializeConfig，fastjson会去寻找仍是创建的代理类，从而复用。关联词淌若new SerializeConfig()，则找不到蓝本生成的代理类，就会一直去生成新的WlkCustomerDto代理类。

底下两张图时问题定位的源码：

咱们将SerializeConfig作为类的静态变量，问题取得了贬责。

private static final SerializeConfig CONFIG = new SerializeConfig();  static {     CONFIG.propertyNamingStrategy = PropertyNamingStrategy.SnakeCase; } 

fastjson SerializeConfig 作念了什么SerializeConfig先容：

SerializeConfig的主邀功能是建立并纪录每种Java类型对应的序列化类(ObjectSerializer接口的收场类)，比如Boolean.class使用BooleanCodec(看定名就知说念该类将序列化和反序列化收场写到一齐了)作为序列化收场类，float[].class使用FloatArraySerializer作为序列化收场类。这些序列化收场类，有的是FastJSON中默许收场的(比如Java基本类)，有的是通过ASM框架生成的(比如用户自界说类)，有的致使是用户自界说的序列化类(比如Date类型框架默许收场是转为毫秒，应用需要转为秒)。天然，这就触及到是使用ASM生成序列化类照旧使用JavaBean的序列化类类序列化的问题，这里判拔除据即是是否Android环境(环境变量"java.vm.name"为"dalvik"或"lemur"即是Android环境)，但判断不仅这里一处，后续还有更具体的判断。

表面上来说，每个SerializeConfig实例若序列化交流的类，齐会找到之前生成的该类的代理类，来进行序列化。们的职业在每次接口被调用时，齐实例化一个ParseConfig对象来建立Fastjson反序列的成立，而未禁用ASM代理的情况下，由于每次调用ParseConfig齐是一个新的实例，因此始终也查验不到仍是创建的代理类，是以Fastjson便胁制的创建新的代理类，并加载到metaspace中，最终导致metaspace胁制膨大，将机器的内存花费。

升级JDK1.8才会出现问题

导致问题发生的原因照旧值得嗜好。为什么在升级之前不会出现这个问题?这就要分析jdk1.8和1.7自带的hotspot诬捏机的互异了。

从jdk1.8运行，自带的hostspot诬捏机取消了畴昔的遥远区，而新增了metaspace区，从功能上看，metaspace不错合计和遥远区雷同，其最主要的功用亦然存放类元数据，但内容的机制则有较大的不同。

起头，metaspace默许的最大值是通盘机器的物理内存大小，是以metaspace胁制膨大会导致java法子侵占系统可用内存，最终系统莫得可用的内存;而遥远区则有固定的默许大小，不会膨大到通盘机器的可用内存。当分拨的内存花费时，两者均会触发full gc，但不同的是遥远区在full gc时，以堆内存回收时雷同的机制去回收遥远区中的类元数据(Class对象)，惟有是根援用无法到达的对象就不错回收掉，而metaspace判断类元数据是否不错回收，是凭证加载这些类元数据的Classloader是否不错回收来判断的，惟有Classloader不可回收，通过其加载的类元数据就不会被回收。这也就解释了咱们这两个职业为什么在升级到1.8之后才出现问题，因为在之前的jdk版块中，天然每次调用fastjson齐创建了许多代理类，在遥远区中加载类许多代理类的Class实例，但这些Class实例齐是在步伐调用是创建的，调用完成之后就不可达了，因此遥远区内存满了触发full gc时，齐会被回收掉。

而使用1.8时，因为这些代理类齐是通过干线程的Classloader加载的，这个Classloader在法子运行的过程中始终也不会被回收，因此通过其加载的这些代理类也始终不会被回收，这就导致metaspace胁制膨大，最终花费机器的内存了。

这个问题并不局限于fastjson，惟有是需要通过法子加载创建类的场地，就有可能出现这种问题。「尤其是在框架中，时时多半聘任雷同ASM、javassist等器用进行字节码增强，而凭证上头的分析，在jdk1.8之前，因为大多数情况下动态加载的Class齐好像在full gc时取得回收，因此圮绝易出现问题」，也因此许多框架、器用包并莫得针对这个问题作念一些处理，一朝升级到1.8之后，这些问题就可能会暴败露来。

总结

皇冠怎么注册

问题贬责了，接下来复盘下通盘排查问题的历程，通盘历程流露了我许多问题，最主要的即是「关于JVM不同版块的内存分拨还不够老到」，导致了关于须生代和元空间判断误差，走了许多弯路，在班师内存中排查了很久，弃世了许多时辰。

其次，排查需要的「一是仔细，二是全面，」，最佳将通盘可能性先行整理好，否则很容易堕入我方设定好的排查限度内，走进死巷子不出来。

终末，总结一下此次的问题带来的成绩：

JDK1.8运行，自带的hostspot诬捏机取消了畴昔的遥远区，而新增了metaspace区，从功能上看，metaspace不错合计和遥远区雷同，其最主要的功用亦然存放类元数据，但内容的机制则有较大的不同。

关于JVM里面的内存需要在启动时进行适度，包括咱们老到的堆内存，也要包括班师内存和元生区，这是保证线上职业平常运行终末的兜底。

使用类库，请多能干代码的写法，尽量不要出现显著的内存泄漏。

关于使用了ASM等字节码增强器用的类库，在使用他们时请多加注重(尤其是JDK1.8以后)。

参考不雅察法子运行时类加载的过程

blog.csdn.net/tenderhearted/article/details/39642275

Metaspace举座先容(遥远代被替换原因、元空间特色、元空间内存稽查分析步伐)

https://www.cnblogs.com/duanxz/p/3520829.html

java内存占用极端问题常见排查历程(含堆外内存极端)

https://my.oschina.net/haitaohu/blog/3024843

JVM源码分析之堆外内存透顶解读

http://lovestblog.cn/blog/2015/05/12/direct-buffer/

JVM 类的卸载

https://www.cnblogs.com/caoxb/p/12735525.html

fastjson在jdk1.8上头开启asm

https://github.com/alibaba/fastjson/issues/385

皇冠体育版源码

fastjson：PropertyNamingStrategy_cn

丰田新皇冠

https://github.com/alibaba/fastjson/wiki/PropertyNamingStrategy_cn

警惕动态代理导致的Metaspace内存泄漏问题

https://blog.csdn.net/xyghehehehe/article/details/78820135

本文转载自微信公众号「后端时候座谈」，不错通过以下二维码热心。转载本文请谈判后端时候座谈公众号。