在jdk8中 -Xms2g不合法，能通过的：-Xms2G
#!/bin/bash
JAVA_OPTS="-Xms4G -Xmx4G -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dump-yyy.log -XX:ErrorFile=./jvm-crash.log -Djava.security.egd=file:/dev/./urandom"
#!/bin/bash
JAVA_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
nohup java -jar $JAVA_OPTS scheduler-0.0.1.jar --spring.profiles.active=dev >/dev/null 2>&1 &
-XX:SurvivorRatio 控制Eden区域和Survivor区域【From幸存区或To幸存区】的内存占用比例。
Eden = (R*Y)/(R+1+1)
From = Y/(R+1+1)
To = Y/(R+1+1)
其中：
R：SurvivorRatio比例
Y：新生代空间大小
-Xmn100M
-XX:SurvivorRatio=8
Eden占80M,Survivor占20M，其中Survivor From和To各占10M
jvm区域总体分两类，heap区和非heap区。
heap区又分：Eden Space（伊甸园）、Survivor Space(幸存者区)、Tenured Gen（老年代-养老区）。
非heap区又分：Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。
hprof
nohup java -jar $JAVA_OPTS demo.jar >/dev/null 2>&1 &
Spring-Boot工程启动参数，spring boot生成的jar，就是一个普通的可执行jar，这个jar的jvm参数需要从java -jar 命令中赋值
设置内存占用最大最小和初始值
要加“m”说明是MB，否则就是KB了.
-Xms：初始值
-Xmx：最大值
-Xmn：年轻代的大小
java -Xms10m -Xmx80m -jar mod.jar &
时区设置
java -jar -Duser.timezone=GMT+08 mod.jar &
https://gumutianqi1.gitbooks.io/specification-doc/content/specification-doc/spring-boot-guide.html
如何查看上面的配置是否生效：
1.首先查看Tomcat 进程号：
ps -ef | grep tomcat
我们可以看到Tomcat 进程号是 9217
1.查看是否配置生效：
sudo jmap –heap 9217
我们可以看到MaxHeapSize 等参数已经生效。
Attaching to process ID 7740, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.60-b23
using thread-local object allocation.
Parallel GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 4294967296 (4096.0MB)
NewSize = 1431306240 (1365.0MB)
MaxNewSize = 1431306240 (1365.0MB)
OldSize = 2863661056 (2731.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 1370488832 (1307.0MB)
used = 1272398256 (1213.4535369873047MB)
free = 98090576 (93.54646301269531MB)
92.84265776490471% used
From Space:
capacity = 18350080 (17.5MB)
used = 17946064 (17.114700317382812MB)
free = 404016 (0.3852996826171875MB)
97.79828752790179% used
To Space:
capacity = 31981568 (30.5MB)
used = 0 (0.0MB)
free = 31981568 (30.5MB)
0.0% used
PS Old Generation
capacity = 2863661056 (2731.0MB)
used = 1815913816 (1731.7903671264648MB)
free = 1047747240 (999.2096328735352MB)
63.41231662857799% used
28392 interned Strings occupying 3370792 bytes.
http://aoyouzi.iteye.com/blog/2302476
使用actuator:
http://localhost:8080/metrics
{
"mem": 4088122,
"mem.free": 3875488,
"processors": 4,
"instance.uptime": 222308,
"uptime": 231631,
"systemload.average": 0.02,
"heap.committed": 4019712,
"heap.init": 4194304,
"heap.used": 144223,
"heap": 4019712,
"nonheap.committed": 70464,
"nonheap.init": 2496,
"nonheap.used": 68411,
"nonheap": 0,
"threads.peak": 49,
"threads.daemon": 37,
"threads.totalStarted": 53,
"threads": 45,
"classes": 8716,
"classes.loaded": 8716,
"classes.unloaded": 0,
"gc.ps_scavenge.count": 3,
"gc.ps_scavenge.time": 86,
"gc.ps_marksweep.count": 2,
"gc.ps_marksweep.time": 133,
"httpsessions.max": -1,
"httpsessions.active": 0
}System metrics
The following system metrics are exposed by Spring Boot:
The total system memory in KB (mem)
The amount of free memory in KB (mem.free)
The number of processors (processors)
The system uptime in milliseconds (uptime)
The application context uptime in milliseconds (instance.uptime)
The average system load (systemload.average)
Heap information in KB (heap, heap.committed, heap.init, heap.used)
Thread information (threads, thread.peak, thread.daemon)
Class load information (classes, classes.loaded, classes.unloaded)
Garbage collection information (gc.xxx.count, gc.xxx.time)
https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-metrics.html中文翻译版：
度量值：
系统信息：包括处理器数量processors、运行时间uptime和instance.uptime、系统平均负载systemload.average。
mem.*：内存概要信息，包括分配给应用的总内存数量以及当前空闲的内存数量。这些信息来自java.lang.Runtime。
heap.*：堆内存使用情况。这些信息来自java.lang.management.MemoryMXBean接口中getHeapMemoryUsage方法获取的java.lang.management.MemoryUsage。
nonheap.*：非堆内存使用情况。这些信息来自java.lang.management.MemoryMXBean接口中getNonHeapMemoryUsage方法获取的java.lang.management.MemoryUsage。
threads.*：线程使用情况，包括线程数、守护线程数（daemon）、线程峰值（peak）等，这些数据均来自java.lang.management.ThreadMXBean。
classes.*：应用加载和卸载的类统计。这些数据均来自java.lang.management.ClassLoadingMXBean。
gc.*：垃圾收集器的详细信息，包括垃圾回收次数gc.ps_scavenge.count、垃圾回收消耗时间gc.ps_scavenge.time、标记-清除算法的次数gc.ps_marksweep.count、标记-清除算法的消耗时间gc.ps_marksweep.time。这些数据均来自java.lang.management.GarbageCollectorMXBean。
httpsessions.*：Tomcat容器的会话使用情况。包括最大会话数httpsessions.max和活跃会话数httpsessions.active。该度量指标信息仅在引入了嵌入式Tomcat作为应用容器的时候才会提供。
gauge.*：HTTP请求的性能指标之一，它主要用来反映一个绝对数值。比如上面示例中的gauge.response.hello: 5，它表示上一次hello请求的延迟时间为5毫秒。
counter.*：HTTP请求的性能指标之一，它主要作为计数器来使用，记录了增加量和减少量。如上示例中counter.status.200.hello: 11，它代表了hello请求返回200状态的次数为11。
对于gauge.*和counter.*的统计，这里有一个特殊的内容请求star-star，它代表了对静态资源的访问。这两类度量指标非常有用，我们不仅可以使用它默认的统计指标，还可以在程序中轻松的增加自定义统计值。只需要通过注入org.springframework.boot.actuate.metrics.CounterService和org.springframework.boot.actuate.metrics.GaugeService来实现自定义的统计指标信息。
JVM自定义参数通过java命令的可选项:
-D<name>=<value>
来传入JVM，传入的参数作为system的property。因此在程序中可以通过下面的语句获取参数值：
System.getProperty(<name>)
public class JVMParameter {
/**
* 运行前设置JVM参数 -Djvm.index=1
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
String jvmIndex = System.getProperty("jvm.index");
System.out.println("jvmIndex=" + jvmIndex);
}
}运行class命令：
Java -Djvm.index=1 JVMParameter
说明：
JVM自定义参数可用来在集群环境区分当前class运行在哪个JVM上，可以达到让某个class只在某个指定的JVM上运行，避免多个JVM同时运行，出现混乱。
C:\>java -help
用法: java [-options] class [args...]
(执行类)
或 java [-options] -jar jarfile [args...]
(执行 jar 文件)
其中选项包括:
-d32 使用 32 位数据模型 (如果可用)
-d64 使用 64 位数据模型 (如果可用)
-server 选择 "server" VM
默认 VM 是 server.
-cp <目录和 zip/jar 文件的类搜索路径>
-classpath <目录和 zip/jar 文件的类搜索路径>
用 ; 分隔的目录, JAR 档案
和 ZIP 档案列表, 用于搜索类文件。
-D<名称>=<值>
设置系统属性
-verbose:[class|gc|jni]
启用详细输出
-version 输出产品版本并退出
java启动参数共分为三类；
其一是标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容；
其二是非标准参数（-X），默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容；
其三是非Stable参数（-XX），此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用；
标准参数中比较有用的：
verbose
-verbose:class
输出jvm载入类的相关信息，当jvm报告说找不到类或者类冲突时可此进行诊断。
-verbose:gc
输出每次GC的相关情况。
-verbose:jni
输出native方法调用的相关情况，一般用于诊断jni调用错误信息。
非标准参数又称为扩展参数
一般用到最多的是
-Xms512m 设置JVM促使内存为512m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmx512m ，设置JVM最大可用内存为512M。
-Xmn200m：设置年轻代大小为200M。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内 存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
-Xloggc:file
与-verbose:gc功能类似，只是将每次GC事件的相关情况记录到一个文件中，文件的位置最好在本地，以避免网络的潜在问题。
若与verbose命令同时出现在命令行中，则以-Xloggc为准。
-Xprof
跟踪正运行的程序，并将跟踪数据在标准输出输出；适合于开发环境调试。
用-XX作为前缀的参数列表在jvm中可能是不健壮的，SUN也不推荐使用，后续可能会在没有通知的情况下就直接取消了；但是由于这些参数中的确有很多是对我们很有用的，比如我们经常会见到的-XX:PermSize、-XX:MaxPermSize等等；
1、堆的大小可以通过 -Xms 和 -Xmx 来设置，一般将他们设置为相同的大小，目的是避免在每次垃圾回收后重新调整堆的大小，比如 -Xms=2g -Xmx=2g 或者 -Xms=512m -Xmx=512m
2、年轻代大小可以通过 -Xmn 来设置，比如-Xmn=2g 或者 -Xmn512m，此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8
3、年老代大小 = 堆大小 – 年轻代大小
4、持久代或者永久代大小可以通过 -XX:PermSize 和 -XX:MaxPermSize 来控制
5、-XX:SurvivorRatio 控制 Eden和Survivor的内存占用比例，默认为8；
如果设置了NewRatio，那么整个堆空间的1/(NewRatio +1)就是新生代空间的大小，-XX:NewRatio推荐2到4.
如果同时指定了NewRatio和NewSize，你应该使用更大的那个。于是，当堆空间被创建时，你可以用过下面的表达式计算初始新生代空间的大小：min(MaxNewSize, max(NewSize, heap/(NewRatio+1)))
三、JVM内存溢出配置
如何能在JVM遇到OOM错误的时候能够打印heap dump?可以设置-XX:+HeapDumpOnOutOfMemoryError参数，让JVM在探测到内存OOM的时候打印dump。但是在JVM启动参数添加这个参数的时候，JVM启动失败：Unrecognized VM option '+HeapDumpOnOutOfMemeryError' ,问题的原因是因为没有添加-XX:HeapDumpPath参数配置。-XX:HeapDumpPath这个参数可以设置dump文件的存放位置。将JVM启动参数设置成如下格式：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:/
问题得到解决。当JVM发生内存溢出的时候，会在C:/下打印出heap dump
常用参数设置
UseParNewGC表示对新生代采用并行gc；
ParallelGCThreads表示并行的线程数为8，一般是cpu的核个数，当核个数大于8时可能不是很适用；
UseConcMarkSweepGC表示对full gc采用CMS gc；
-XX:+DisableExplicitGC 表示禁止显式gc，System.gc()
-XX:+UseCMSCompactAtFullCollection 适用于CMS gc，表示在进行gc的同时清理内存碎片，但会加长gc的总时间
-XX:CMSInitiatingOccupancyFraction=80 适用于CMS gc，表示在年老代达到80%使用率时马上进行回收
在JVM Crash时获heap信息的一些配置参数：
-XX:ErrorFile=./xxx.log JVM Crash时记录heap信息
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./yyy.log
Trace跟踪参数
-verbose:gc
-XX:+printGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:log/gc.log // 指定GC log的位置，以文件输出
-XX:PrintHeapAtGC // 每一次GC后，都打印堆信息
// 类加载信息
-XX:TraceClassLoading
-XX:+PrintClassHistogram
-Ctrl +Break 打印类信息， 类的使用情况
五、类的加载
类加载有三种方式：
1、命令行启动应用时候由JVM初始化加载
2、通过Class.forName()方法动态加载
3、通过ClassLoader.loadClass()方法动态加载
三种方式区别比较大，看个例子就明白了：
public class HelloWorld {
public static void main(String[] args) throws ClassNotFoundException {
ClassLoader loader = HelloWorld.class.getClassLoader();
System.out.println(loader);
//使用ClassLoader.loadClass()来加载类，不会执行初始化块
loader.loadClass("Test2");
//使用Class.forName()来加载类，默认会执行初始化块
// Class.forName("Test2");
//使用Class.forName()来加载类，并指定ClassLoader，初始化时不执行静态块
// Class.forName("Test2", false, loader);
}
}
public class Test2 {
static {
System.out.println("静态初始化块执行了！");
}
}
分别切换加载方式，会有不同的输出结果。
http://lavasoft.blog.51cto.com/62575/184547/
Java程序运行的场所是内存，当在命令行下执行：
java HelloWorld
命令的时候，JVM会将HelloWorld.class加载到内存中，并形成一个Class的对象HelloWorld.class。
其中的过程就是类加载过程：
1、寻找jre目录，寻找jvm.dll，并初始化JVM；
2、产生一个Bootstrap Loader（启动类加载器）；
3、Bootstrap Loader自动加载Extended Loader（标准扩展类加载器），并将其父Loader设为Bootstrap Loader。
4、Bootstrap Loader自动加载AppClass Loader（系统类加载器），并将其父Loader设为Extended Loader。
5、最后由AppClass Loader加载HelloWorld类。
以上就是类加载的最一般的过程。
1、Bootstrap Loader（启动类加载器）：加载System.getProperty("sun.boot.class.path")所指定的路径或jar。
2、Extended Loader（标准扩展类加载器ExtClassLoader）：加载System.getProperty("java.ext.dirs")所指定的路径或jar。在使用Java运行程序时，也可以指定其搜索路径，例如：java -Djava.ext.dirs=d:\projects\testproj\classes HelloWorld
3、AppClass Loader（系统类加载器AppClassLoader）：加载System.getProperty("java.class.path")所指定的路径或jar。在使用Java运行程序时，也可以加上-cp来覆盖原有的Classpath设置，例如： java -cp ./lavasoft/classes HelloWorld
ExtClassLoader和AppClassLoader在JVM启动后，会在JVM中保存一份，并且在程序运行中无法改变其搜索路径。如果想在运行时从其他搜索路径加载类，就要产生新的类加载器。
http://lavasoft.blog.51cto.com/62575/184547/
java一般使用两个path：classpath 和 java.library.path
classpath是指向jar包的位置
java.library.path是非java类包的位置如（dll,so）
解决办法：
1：LINUX下的系统变量LD_LIBRARY_PATH来添加java.library.path
2：在vm arguments里添加-Djava.library.path= /usr/local/lib
3：见下图
开发、应用中老是会遇到OutOfMemory异常，而且常常是过一段时间内存才被吃光，这里可以利用java heap dump出jvm内存镜像，然后再对其进行分析来查找问题。
《java heap dump触发和分析》这篇文章很好的介绍了heap dump的方法和分析的工具。
平常利用jmap -dump:format=b,file=/path/file.hprof <pid> 这个java自带的工具来dump heap很方便，但当内存溢出问题发生的比较快的情况下，该命令就有可能来不及或无效。
这个时候在应用启动时配置相关的参数 -XX:+HeapDumpOnOutOfMemoryError就比较方便，当然可以再加上-XX:HeapDumpPath=/path/file.hprof 来指定文件的输出路径。
不知道怎么用这些参数？就在你启动应用的时候加，如：
/usr/lib/jvm/java-1.6.0/bin/java -server -Xms1536m -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=64m -XX:MaxPermSize=64m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/file.hprof -Djava.ext.dirs=/xxx/lib/ ClassName
在《java heap dump触发和分析》里有介绍到分析工具，个人觉得利用java自带的 $JAVA_HOME/bin/jhat -J-Xmx512m /path/file.hprof工具看分析结果不是很友好，当然这情况紧急、身边又没工具的情况下也是一个好的选择。但个别比较推荐里面介绍的IBM HeapAnalyzer(没用过)和MemoryAnalyzer，关于MemoryAnalyzer的介绍可以看下使用 Eclipse Memory Analyzer 进行堆转储文件分析里的介绍。
如果嫌配置-classpath麻烦,可以用-Djava.ext.dir 参数替代,这样就可以批量引入jar包.
但是有个问题需要注意,java默认用的ext目录是$JAVA_HOME/jre/lib/ext,所以如果你指定了-Djava.ext.dir 参数,则原$JAVA_HOME/jre/lib/ext下的jar包将不会被引用,可能会导致你的程序出现问题;
例如有用到SSL协议的地方会出现javax.net.ssl.SSLKeyException: RSA premaster secret error 异常.
最近我在项目中通过jdbc连接sqlserver2008时出现过这样的问题,就是因为用-Djava.ext.dir 参数替代了-classpath.
解决方法是将$JAVA_HOME/jre/lib/ext下的dnsns.jar，localedata.jar，sunjce_provider.jar，sunpkcs11.jar放置到你指定的java.ext.dir目录下.
为了防止出现莫名其妙的错误,最好整个$JAVA_HOME/jre/lib/ext下的jar包都copy过去.
参考:
http://jony-hwong.iteye.com/blog/315324
http://t8500071.iteye.com/blog/790676
本地部署时抛出异常java.lang.OutOfMemoryError：GC overhead limit exceeded导致服务起不来，查看日志发现加载了太多资源到内存，本地的性能也不好，gc时间消耗的较多。解决这种问题两种方法是，增加参数，-XX:-UseGCOverheadLimit，关闭这个特性，同时增加heap大小，-Xmx1024m。坑填了，but why？
OOM大家都知道，就是JVM内存溢出了，那GC overhead limit exceed呢？
GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略，通过统计GC时间来预测是否要OOM了，提前抛出异常，防止OOM发生。Sun 官方对此的定义是：“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是，超过98%的时间用来做GC并且回收了不到2%的堆内存。用来避免内存过小造成应用不能正常工作。“
听起来没啥用...预测OOM有啥用？起初开来这玩意只能用来Catch住释放内存资源，避免应用挂掉。后来发现一般情况下这个策略不能拯救你的应用，但是可以在应用挂掉之前做最后的挣扎，比如数据保存或者保存现场（Heap Dump）。
而且有些时候这个策略还会带来问题，比如加载某个大的内存数据时频繁OOM。
假如你也生产环境中遇到了这个问题，在不知道原因时不要简单的猜测和规避。可以通过-verbose:gc -XX:+PrintGCDetails看下到底什么原因造成了异常。通常原因都是因为old区占用过多导致频繁Full GC，最终导致GC overhead limit exceed。如果gc log不够可以借助于JProfile等工具查看内存的占用，old区是否有内存泄露。分析内存泄露还有一个方法-XX:+HeapDumpOnOutOfMemoryError，这样OOM时会自动做Heap Dump，可以拿MAT来排查了。还要留意young区，如果有过多短暂对象分配，可能也会抛这个异常。
日志的信息不难理解，就是每次gc时打条日志，记录GC的类型，前后大小和时间。举个例子。
33.125: [GC [DefNew: 16000K->16000K(16192K), 0.0000574 secs][Tenured: 2973K->2704K(16384K), 0.1012650 secs] 18973K->2704K(32576K), 0.1015066 secs]
100.667:[Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 0.0150007 secs]
GC和Full GC代表gc的停顿类型，Full GC代表stop-the-world。箭头两边是gc前后的区空间大小，分别是young区、tenured区和perm区，括号里是该区的总大小。冒号前面是gc发生的时间，单位是秒，从jvm启动开始计算。DefNew代表Serial收集器，为Default New Generation的缩写，类似的还有PSYoungGen，代表Parallel Scavenge收集器。这样可以通过分析日志找到导致GC overhead limit exceeded的原因，通过调节相应的参数解决问题。
文中涉及到的名词解释，
Eden Space：堆内存池，大多数对象在这里分配内存空间。
Survivor Space：堆内存池，存储在Eden Space的gc中存活下来的对象。
Tenured Generation：堆内存池，存储Survivor Space中存活过几次gc的对象。
Permanent Generation：非堆空间，存储的是class和method对象。
Code Cache：非堆空间，JVM用来存储编译和存储native code。
最后附上GC overhead limit exceed HotSpot的实现：
bool print_gc_overhead_limit_would_be_exceeded = false;
if (is_full_gc) {
if (gc_cost() > gc_cost_limit &&
free_in_old_gen < (size_t) mem_free_old_limit &&
free_in_eden < (size_t) mem_free_eden_limit) {
// Collections, on average, are taking too much time, and
// gc_cost() > gc_cost_limit
// we have too little space available after a full gc.
// total_free_limit < mem_free_limit
// where
// total_free_limit is the free space available in
// both generations
// total_mem is the total space available for allocation
// in both generations (survivor spaces are not included
// just as they are not included in eden_limit).
// mem_free_limit is a fraction of total_mem judged to be an
// acceptable amount that is still unused.
// The heap can ask for the value of this variable when deciding
// whether to thrown an OutOfMemory error.
// Note that the gc time limit test only works for the collections
// of the young gen + tenured gen and not for collections of the
// permanent gen. That is because the calculation of the space
// freed by the collection is the free space in the young gen +
// tenured gen.
// At this point the GC overhead limit is being exceeded.
inc_gc_overhead_limit_count();
if (UseGCOverheadLimit) {
if (gc_overhead_limit_count() >=
AdaptiveSizePolicyGCTimeLimitThreshold){
// All conditions have been met for throwing an out-of-memory
set_gc_overhead_limit_exceeded(true);
// Avoid consecutive OOM due to the gc time limit by resetting
// the counter.
reset_gc_overhead_limit_count();
} else {
// The required consecutive collections which exceed the
// GC time limit may or may not have been reached. We
// are approaching that condition and so as not to
// throw an out-of-memory before all SoftRef's have been
// cleared, set _should_clear_all_soft_refs in CollectorPolicy.
// The clearing will be done on the next GC.
bool near_limit = gc_overhead_limit_near();
if (near_limit) {
collector_policy->set_should_clear_all_soft_refs(true);
if (PrintGCDetails && Verbose) {
gclog_or_tty->print_cr(" Nearing GC overhead limit, "
"will be clearing all SoftReference");
}
}
}
}
// Set this even when the overhead limit will not
// cause an out-of-memory. Diagnostic message indicating
// that the overhead limit is being exceeded is sometimes
// printed.
print_gc_overhead_limit_would_be_exceeded = true;
} else {
// Did not exceed overhead limits
reset_gc_overhead_limit_count();
}
}