JVM堆引发swap的情况分析

最新推荐文章于 2024-03-16 19:23:37 发布
转载 最新推荐文章于 2024-03-16 19:23:37 发布 · 2.3k 阅读 · 8 ·
CC 4.0 BY-SA版权
原文链接：https://my.oschina.net/u/1000241/blog/3094585
文章标签：

#大数据 #数据库 #5g

本文探讨了JVM堆内存分配过大导致的swap情况，解释了Linux系统如何在物理内存不足时使用swap内存，以及虚拟内存分配超过物理内存时为何引发swap而非GC。此外，还分析了直接内存、线程并发量对swap的影响，提出了解决swap异常的方案，包括检查线程使用和增加物理内存。

写在前面

虚拟机技术可以使得一个只有1g物理内存的机器可以运行总共需要4g内存的任务，主要方法是通过虚拟内存和物理内存映射来实现的，当物理内存不够用的时候，可以通过swap内存(存在于磁盘)和物理内存的交换来释放刚交换的物理内存，使其可以重新分配，当需要使用以前换出的内存时，在进行换入操作。

但是内存到磁盘换入换出操作十分占用CPU，因此在线上应该限制swap区的大小，如果swap占用比例较高应该进行排查和解决。

是否活跃虚拟内存大于物理内存

以jdk8为例，配置如下：

CUSTOM_JVM = -Xmx5g -Xms5g -Xmn2g -server -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=0 -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=68 -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails

首先怀疑因为metaspace没有达到最大内存限制，因此无限增大，并且不执行fullgc，造成新分配的young对象分配时没有达到最大的NewSize，从而引起物理内存和虚拟内存的swap操作。

可以通过jstat -gccapacity pid分析GC情况，以判断年轻代，年老代，metaspace区的晋升状态。

通过TOP命令查看内存使用情况，java进程只使用了6.5G内存，但是虚拟内存达到了13G。

Tasks: 136 total,   1 running, 135 sleeping,   0 stopped,   0 zombie
Cpu(s):  7.0%us,  3.7%sy,  0.0%ni, 88.6%id,  0.0%wa,  0.0%hi,  0.3%si,  0.4%st
Mem:   8059416k total,  7747344k used,   312072k free,    20048k buffers
Swap:  2096440k total,  1993920k used,   102520k free,   368492k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16907 sankuai   20   0 13.0g 6.5g 6880 S 41.6 84.4   1965:06 java
 5063 sankuai   20   0 1916m  24m 2884 S  6.3  0.3 171:42.18 cplugin
  676 sankuai   20   0  839m 6568 1600 S  0.3  0.1 288:01.72 log_agent
 9317 root      20   0 1350m 9348 2940 S  0.3  0.1  24:25.22 falcon-agent
    1 root      20   0 39952  300  132 S  0.0  0.0   0:01.92 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      RT   0     0    0    0 S  0.0  0.0   0:11.90 migration/0

为什么过多的分配虚拟内存会引起swap而不会引起gc？

linux中物理内存是linux的主要内存区域，当物理内存不够时，linux会把一部分暂时不使用的内存数据放到磁盘swap区去，以便腾出更多可用内存空间。当需要使用位于swap区的数据时，必须先将其换回内存中。

整个内存区域分为：内核内存和用户内存。

虚拟内存技术给每一个进程一定虚拟内存空间，只有当虚拟内存实际被使用时，才分配物理内存，通过虚拟内存技术+swap内存可以使得每个用户进程使用的虚拟地址大小是一样的，并且可以大于实际物理内存空间。当一个虚拟内存准备映射到物理内存时，发现没有空闲的物理内存，操作系统会在已经被其他进程使用或者还没有立即使用的物理空间和swap内存进行交换，从而将置换出的物理内存分配给进程。swap过程相当影响性能。

为什么虚拟内存分配大小>物理内存时引起swap操作而不是gc操作？

对于linux系统而言，其只可以运行可执行的二进制代码，jvm进程本身是一个C语言开发的进程，因此其在使用虚拟内存时和其他普通的linux进程一样。

虚拟内存用户内存部分分成以下几部分：

  1. 代码区，linux进程的代码
  2. 数据区，linux进程的全局或者静态数据等
  3. 堆区，运行时数据动态申请的空间，程序运行时直接申请/释放的内存资源
  4. 栈区，存放函数的入参，临时变量，及地址返回值数据等
  5. 未使用区

对于JVM而言，在启动时会将自己jvm进程的全局或者静态变量存放的数据区，同时jvm进程代码放入代码区，并且申请一整块虚拟内存作为堆区给jvm中的线程使用，其中包括了jvm中的年轻代，年老代，永久代。

如果设置过大的堆区或者过大的元空间，会引起swap操作。堆大小通过Xmx，Xms设置，元空间通过MetaspaceSize设置。jdk8中该大小只是表示虚拟内存大小，并不会完全映射到物理内存(会按照一定比例申请一部分内存)，但是这个值会作用到垃圾回收的阈值上。

如果未达到设置容量值，但是物理内存不够时，会将一些不再活跃的内存替换到swap中，从而分配给jvm使用。

我们看一幅图：

jvm启动时会分配100g虚拟内存，实际使用的内存有40g，其原理是通过swap实现的。所以过大的设置虚拟内存会引起swap操作而不是gc操作。

当我们手动触发一次fullgc，发现使用的空间只有3g。

所以在设置jvm参数时建议显示的设置：MaxMetaspaceSize 值，因为默认是无穷大的，如果无休止的使用被os kill。

直接内存和swap的关系

jvm参数默认加上了-XX:+DisableExplicitGC参数，可以在用户调用system.gc时被忽略不引起gc过程。

system.gc调用不一定立即引起fullgc，具体情况视jvm自己决定，此参数可以防止用户提醒jvm进行垃圾回收。

DisableExplicitGC 也可能引起swap操作，我们通过XX:MaxDirectMemorySize 来限制直接内存大小，因此直接内存可以无限使用。

线程并发量过大引起swap

并发线程数量过大可以引起jvm线程栈占用物理内存过大，最终可能引起swap情况。

比如jvm使用内存大约使用了1.62g(最大swap区大小为2g)。当swap区增大的同一时间，观察线程数量可以发现同一时间线程数量峰值达到了650个，大约占swap区650m(每个线程1m)。

观察近3天线程和swap情况，发现所有发生swap异常的时机，线程数量都有激增，可以肯定swap异常和并发线程数量有直接关系。

通过top查看物理内存使用情况：

jvm内存使用情况：5g(堆内存)+0.5g(堆外内存)+0.7g(栈内存)+0.5g(meta内存)+其他内存+linux内存，再加上其他占用物理内存必定会触发使用swap区空间。

swap会占用cpu的，因此在高qps时候会引起性能下降。

可以有两种方案解决：

  1. 查看是否有错误使用线程的情况
  2. 申请加大机器内存

上面情况说明，swap区增高和jvm线程数量强相关，和qps强相关，需要看下机器线程使用情况。

排查是否存在错误使用线程情况：

[xxx@xxxx ~]$ jstack 3082 | grep 'java.lang.Thread.State' | awk '{print $2,$3,$4,$5}' | sort | uniq -c
      1 BLOCKED (on object monitor)
    119 RUNNABLE
     25 TIMED_WAITING (on object monitor)
    106 TIMED_WAITING (parking)
     26 TIMED_WAITING (sleeping)
     15 WAITING (on object monitor)
    207 WAITING (parking)
[xxx@xxxx ~]$

统计各个线程出现次数：

[xxx@xxxx ~]$ jstack 3082 | grep 'tid.*nid' | awk -F '"' '{print $2}' | cut -d - -f 1 | cut -d# -f 1 | sort | uniq  -c | sort -k1 -nr
     80 Thread
     53 DynamicAgentCluster
     44 Pigeon
     24 com.sankuai.meituan.waimai.wdc.service.IRelationService
     20 jetty
     18 MySQL Statement Cancellation Timer
     18 jedis
     16 New I/O worker
     12 pool
     10 Curator
     10 com.sankuai.meituan.waimai.wdc.service.IWmTagService
     10 com.sankuai.meituan.waimai.wdc.service.IWdcPoiQueryService
     10 com.sankuai.meituan.waimai.wdc.service.IWdcMergeGroupService
     10 com.sankuai.meituan.waimai.wdc.service.ISubversiveService
     10 com.sankuai.meituan.waimai.wdc.service.ISimilarPoiRecommendService
     10 com.sankuai.meituan.waimai.wdc.service.IPublicSeaPoiReportAuditService
     10 com.sankuai.meituan.waimai.wdc.service.IPoiSegmentService
     10 com.sankuai.meituan.waimai.wdc.service.IOuterRelationService
     10 com.sankuai.meituan.waimai.wdc.service.IGeoCodeService
     10 com.sankuai.meituan.waimai.wdc.service.IBrandService
     10 com.sankuai.meituan.waimai.wdc.service.IBrandRelationService
     10 com.sankuai.meituan.waimai.wdc.service.IAutoAuditService
      8 main
      8 elasticsearch[Big Wheel][transport_client_worker][T
      8 api
      5 XMDFileAppender
      5 tair
      4 Gang worker
      4 Druid
      3 cat
      3 AsyncAppender
      2 Timer
      2 TAsyncClientManager
      2 metrics
      2 avatar
      1 VM Thread
      1 VM Periodic Task Thread
      1 TraceCollector
      1 threadDeathWatcher
      1 Tair
      1 Surrogate Locker Thread (Concurrent GC)
      1 Squirrel
      1 squirrel
      1 Signal Dispatcher
      1 Service Thread
      1 Reference Handler
      1 pollingConfigurationSource
      1 org.eclipse.jetty.util.RolloverFileOutputStream
      1 nioEventLoopGroup
      1 New I/O server boss
      1 New I/O boss
      1 mtthrift
      1 mtrace
      1 MnsCacheManager
      1 mafka
      1 lion
      1 JMonitor Http Agent Sender for app[]
      1 jmonitor
      1 HashSessionScavenger
      1 Hashed wheel timer
      1 Finalizer
      1 FalconCollect
      1 elasticsearch[Big Wheel][transport_client_timer][T
      1 elasticsearch[Big Wheel][transport_client_boss][T
      1 elasticsearch[Big Wheel][[timer]]
      1 elasticsearch[Big Wheel][scheduler][T
      1 elasticsearch[Big Wheel][generic][T
      1 DestroyJavaVM
      1 ConfigCacheManager
      1 Concurrent Mark
      1 commons
      1 C2 CompilerThread1
      1 C2 CompilerThread0
      1 C1 CompilerThread2
      1 Attach Listener
      1 AsyncLoggerConfig
      1 AsyncLogger
      1 Abandoned connection cleanup thread
      1 1429208949@qtp
      1 1171978040@qtp

线程waiting情况：

[xxx@xxxx ~]$ jstack 3082 | grep -B1 'java.lang.Thread.State.*WAITING' | grep 'tid.*nid' | awk -F '"' '{print $2}' | cut -d - -f 1 | cut -d# -f 1 | sort | uniq  -c | sort -k1 -nr
     53 DynamicAgentCluster   //该线程是一个scheduleAtFixedRate的线程，其是Thrift用于从OCTO中获取指定appkey对应的serverLists，每个ThriftClient都会有一个thread
     44 Pigeon
     37 com.sankuai.meituan.waimai.wdc.service.IRelationService
     18 MySQL Statement Cancellation Timer
     16 jetty
     15 Thread
     15 jedis
     12 pool
     10 Curator
     10 com.sankuai.meituan.waimai.wdc.service.IWmTagService
     10 com.sankuai.meituan.waimai.wdc.service.IWdcPoiQueryService
     10 com.sankuai.meituan.waimai.wdc.service.IWdcMergeGroupService
     10 com.sankuai.meituan.waimai.wdc.service.ISubversiveService
     10 com.sankuai.meituan.waimai.wdc.service.ISimilarPoiRecommendService
     10 com.sankuai.meituan.waimai.wdc.service.IPublicSeaPoiReportAuditService
     10 com.sankuai.meituan.waimai.wdc.service.IPoiSegmentService
     10 com.sankuai.meituan.waimai.wdc.service.IOuterRelationService
     10 com.sankuai.meituan.waimai.wdc.service.IGeoCodeService
     10 com.sankuai.meituan.waimai.wdc.service.IBrandService
     10 com.sankuai.meituan.waimai.wdc.service.IBrandRelationService
     10 com.sankuai.meituan.waimai.wdc.service.IAutoAuditService
      8 api
      5 XMDFileAppender
      4 main
      4 Druid
      3 cat
      3 AsyncAppender
      2 Timer
      2 metrics
      2 avatar
      1 TraceCollector
      1 threadDeathWatcher
      1 Tair
      1 Squirrel
      1 squirrel
      1 Reference Handler
      1 pollingConfigurationSource
      1 org.eclipse.jetty.util.RolloverFileOutputStream
      1 mtthrift
      1 mtrace
      1 MnsCacheManager
      1 mafka
      1 lion
      1 JMonitor Http Agent Sender for app[]
      1 jmonitor
      1 HashSessionScavenger
      1 Hashed wheel timer
      1 Finalizer
      1 FalconCollect
      1 elasticsearch[Big Wheel][transport_client_timer][T
      1 elasticsearch[Big Wheel][[timer]]
      1 elasticsearch[Big Wheel][scheduler][T
      1 elasticsearch[Big Wheel][generic][T
      1 ConfigCacheManager
      1 commons
      1 AsyncLoggerConfig
      1 AsyncLogger
      1 Abandoned connection cleanup thread
      1 1429208949@qtp

需要排查那些wait的线程情况：

  • 53 DynamicAgentCluster：美团thrift rpc框架，每个rpc客户端都有一个线
  • 44 Pigeon：点评pigeon rpc框架：其会分配一些线程来获取最新的服务器信
  • 18 MySQL Statement Cancellation Timer：mysql事务超时判断timer
  • 16 jetty: 阻塞中的jetty工作线程
  • 15 jedis: jedis相关线程，包括renew-slots的slot重新分配以及相关的请求线
  • com.sankuai.meituan.waimai.wdc.service: 和业务请求相关的线程，可以发现这个占比较大。

最终结论线程使用合理，大量线程的产生式因为请求量的递增相关。

申请大物理内存机器：

将机器从8g内存扩展到16g内存，解决了swap异常。

8g内存：

16g内存：

转载于:https://my.oschina.net/u/1000241/blog/3094585

chunyusi1569
关注
堆外内存 OOM：现象分析与优化方案
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
03-30 11万+
本文分析了 Java 中堆外内存泄漏及其引发的 OOM 问题，重点讨论了主动申请未释放和 JNI 调用未释放的两大原因。提供了排查策略，如启用 Native Memory Tracking（NMT）和监控堆外内存使用。并提出了优化方案，包括合理管理堆外内存、设置内存限制及定期监控，帮助避免内存泄漏对系统性能的影响。
从ES的JVM配置起步思考JVM常见参数优化
最新发布
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
12-03 9万+
Java 8目前仍然是许多企业中主要使用的版本之一，尤其是对于比较保守的公司。在过去，CMS (Concurrent Mark-Sweep) 垃圾回收器在Java 8中是一种常见选择，因为它在某些场景下能够提供较好的性能。然而，随着Java版本的不断更新，一些旧的特性和组件被淘汰或替代，比如CMS。Java 14中正式废弃了CMS，而新的垃圾回收器，如ZGC和G1，逐渐成为了主流选择。ZGC和G1在处理大内存堆和低停顿时间方面表现出色，适用于现代应用程序的需求。
jvm调优-swap内存交换
LJ66666688的博客
03-22 949
3：物理内存不够用，大量JVM的堆内存被交换到swap之后，垃圾回收时把swap内存交换到物理内存，但swap的内存又不会立即交换回来。1：系统内存足够(jvm内存未使用到swap内存)，但jvm内存不够，最终导致jvm的频繁垃圾回收（FGC），由于fullgc时间很久，会导致线程的长期暂停。2：系统内存不够，JVM堆内存部分用到了swap，此时的垃圾回收需要把swap的内存交换到系统物理内存再进行jvm的垃圾回收。虚拟内存的出现，让机器内存不够的情况得到部分解决。机制，杀掉占用内存最大的进程。
JVM GC机制
lwyiwan的专栏
06-27 793
[Java性能剖析]Sun JVM内存管理和垃圾回收 内存管理和垃圾回收是JVM非常关键的点，对Java性能的剖析而言，了解内存管理和垃圾回收的基本策略非常重要。本篇对Sun JVM 6.0的内存管理和垃圾回收做大概的描述。      1.内存管理       在程序运行过程当中，会创建大量的对象，这些对象，大部分是短周期的对象，小部分是长周
JVM原理和优化
weixin_34363171的博客
08-08 386
本文转自 ：http://blog.youkuaiyun.com/ning109314/article/details/10411495 JVM工作原理和特点主要是指操作系统装入JVM是通过jdk中Java.exe来完成,通过下面4步来完成JVM环境. 1.创建JVM装载环境和配置 2.装载JVM.dll 3.初始化JVM.dll并挂界到JNIENV(JNI调用接口)实例 4.调用JNIEnv实例装...
关于JVM INSTR swap赋值
水墨青花的专栏
07-26 816
源码： return new Token(_$2.substring(0, _$4()),_$3,_$3 + _$4()); 反编译后： Token _$27() { JVM INSTR new #15 ; JVM INSTR dup ; JVM INSTR swap ; _$2.substring(0,
JVM 内存调优 ——Heap设定与垃圾回收
youer511的专栏
07-20 1334
Java Heap分为3个区：Young,Old和Permanent.        Young保存刚实例化的对象 .当该区被填满时,GC会将对象移到Old区.        Permanent区则负责保存反射对象,本文不讨论该区 .       JVM的Heap分配可以使用-X参数设定,       -Xms     初始Heap大小       -Xmx     java he
JVM高频面试基本问题与知识点整理
热门推荐
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
01-16 86万+
JVM高频面试基本问题与知识点整理
JVM内存问题排查
偶尔写些东西，意思一下我也参与了内卷
01-25 1568
JVM 的堆空间分成2个区域：年轻代、老年代年轻代又进一步细分成3个区域：Eden、Survivor From、Survivor To。
OOM内存溢出 JVM线上故障 系统突然抖动 卡死 各种超时 JVM优化思路解析 实战分析记录JVM Merry christmas圣诞节的OOM《持续更新》
weixin_46950473的博客
12-25 1644
前言 看过很多技术文档，也浏览过很多种技术方案，也实际上简单了解上手和面临过类似这种线上问题，但是一直没有一个很完整的一个记录，JVM调优，一个看起来很高大上，但是一个基本上现在的Java工程师都需要掌握和面试必须要经历的一个技术，但实际上能在公司真正的线上能去上手调优的机会少之极少，很多人可能谈吐起JVM，哗啦哗啦，但是实际上一上手，就可能会小鹿乱撞，但是线上的系统，实际上试错率几乎为0，所以这样的机会，在大型互联网，或者是互联网公司，是压根给不了这个尝试性去调优jvm的机会的，这次分享一个我们线上的问
java swap空间_有没有办法强制JVM使用swap，无论内存需求有多大？
weixin_39844284的博客
02-26 737
正如其他答案所指出的，您使用 -Xmx 开关为JVM提供更多RAM .但是，你可以走多远就有限制 . 在32位系统上，如果JVM支持它，它可能是2GiB，可能是3或4 GiB . 根据Java -Xmx, Max memory on system，对于Sun JVM，32位Windows上的限制为1500MiB .出于基本架构原因，进程不能(没有特殊技术)获得超过4 GiB的内存(包括它可能使用的...
JVM--调优--04--案例05--SWAP导致的Full GC时间长
zhou920786312的博客
03-16 928
当系统运行一段时间，放到内存的对象变多，且有些对象是暂时没有用，持续一段时间后，发现内存不够了，这个时候SWAP会将。由于SWAP位于磁盘上，读写数据的速度相比物理内存会慢得多，因此过度使用SWAP可能导致系统性能下降。因此，SWAP实际上扩大了系统的可用内存，使得即使在存不足的情况下，也能运行大内存的应用程序。所以每次Full GC，CPU和内存都会升高，SWAP会降低。当物理内存不足时，SWAP 会将内存中暂时不用的数据 放到。当发生FULL GC的时候，需要分析所有对象，这个时候会把。
为什么设置-Xmx4g但是java进程内存占用达到8g？
弹指天下
01-28 2万+
前言 不知道大家在开发过程中有没有遇到过类似的问题，明明通过JVM参数-Xmx4g设置了最大堆内存大小为4g，但是程序运行一段时间后发现占用的内存明显超过了8g，却并没有出现内存溢出等问题，那是什么东西占用了额外的内存空间呢？ 一、背景 1.通过free -g查看服务器内存使用情况 2.通过ps查看java进程 项目启动命令为： java -Xmx6g -Xms6g - -XX:+UseG1GC -jar /home/pgcp/pgcp-0.0.1-SNAPSHOT.jar 3.通过top命令查看资
JVM "Out of swap space"错误常见的原因
xianqi_h的专栏
08-01 595
Out of swap space error generally occurs when your native heap is running out of memory not the java heap.The following could be the suspects which may leak the native memory: 1) JDBC Objects if it i...
JVM 调优 —— GC 长时间停顿问题及解决方法
WGH100817的博客
04-16 468
零. 简介 垃圾收集器长时间停顿，表现在 Web 页面上可能是页面响应码 500 之类的服务器错误问题，如果是个支付过程可能会导致支付失败，将造成公司的直接经济损失，程序员要尽量避免或者说减少此类情况发生。 一. 并发模式失败（concurrent mode f...
java swap空间_故障重现(内存篇2)，JAVA内存不足导致频繁回收和swap引起的性能问题...
weixin_34079693的博客
02-26 1079
背景起因：记起以前的另一次也是关于内存的调优分享下有个系统平时运行非常稳定运行(没经历过大并发考验)，然而在一次活动后，人数并发一上来后，系统开始卡。我按经验开始调优，在每个关键步骤的加入如下代码耗时统计进行压测：long startTime = System.currentTimeMillis();callRpc(); //这里比如调用RPC伪代码，当然还在插入数据库，中间件地方都加入统计l...
JVM调优-配置参数
言午玉口才
08-22 726
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
linux Java服务swap分区被占用内存泄露问题故障及解决方法
走向CTO的路上...
09-06 1145
鱼弦：优快云内容合伙人、优快云新星导师、全栈领域创作新星创作者 、51CTO(Top红人+专家博主) 、github开源爱好者（go-zero源码二次开发、游戏后端架构 https://github.com/Peakchen）当Java服务在Linux系统中运行时，可能会出现swap分区被占用的内存泄露问题，导致系统性能下降或者崩溃。下面是该问题的故障及解决方法、底层结构、架构图、工作原理、使用场景详解和实际应用方式、原理详细描述、相关命令使用示例以及文献材料链接。
Linux swap分区工作原理及问题定位
C-Jonn
05-01 1113
#目录部分 一、文件页和匿名页 1、文件页 当发生了内存泄漏时，或者运行了大内存的应用程序，导致系统的内存资源紧张时，系统又会如何应对呢？内存回收和 OOM 杀死进程。 内存资源紧张导致的 OOM（Out Of Memory），指的是系统杀死占用大量内存的进程，释放这些内存，再分配给其他更需要的进程。 内存回收，也就是系统释放掉可以回收的内存，比如缓存和缓冲区，就属于可回收内存。它们在内存管理中，通常被叫做文件页（File-backed Page）。 大部分文件页，都可以直接回收，以后有需.
Java堆内存溢出问题分析与解决方案
堆大小应控制在物理内存的80%以内，以防止操作系统因内存不足而频繁使用虚拟内存（Swap），进而引发严重的性能下降甚至系统卡顿。此外，过大的堆可能导致长时间的Full GC（全局垃圾回收），造成应用暂停（Stop-The-...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值