内存监控
-verbose:gc 或-XX:printGC在控制台打印gc的回收情况
这里分配了 堆内存xmx最大3M 最小3M 执行空的main方法
造成的gc的原因是回收main方法执行之前产生的垃圾对象(没有变量引用的对象)
-XX:+PrintGCDetails 配合( -verbose:gc使用）
打印每次gc的回收情况 执行完毕后打印堆空间的内存信息
PsYoungGen 为新生代 总内存(total1024k ) 使用（used 524K） 其中：
eden区 512K
from区 512K
to区 521K
可以发现eden+from+to不等于1024 新生代的内存为eden+from或者+to
ParOldGen 为老年代 总空间2560K
Metaspace PermGen永久代废弃 jdk8使用 Metaspace(元空间) 替代
-verbose:gc -XX:+PrintGCTimeStamps
打印每次gc的间隔的时间戳 full gc为每次对新生代老年代以及整个空间做统一的回收 系统中应该尽量避免
产生fullgc的几种情况 老年代空间不足 持久代(元空间 或者jdk8的元空间)空间不足 手动调用system.gc 可以使用可以DisableExplicitGC来禁止
-XX:+TraceClassLoading
打印类加载情况
-XX:+PrintClassHistogram 打印每个类的实例的内存占用情况
-XX:+PrintHeapAtGC 打印每次gc前后的内存情况
回收前年轻代使用1140K 都在eden区使用55% 回收后 年轻代使用488K 清空eden去垃圾对象 非垃圾对象 放到from区
-Xloggc:path 将gc的日志文件打印到指定文件 如d:\log\gc.log(配合上面的监控参数)
-XX：HeapDumpOnOutOfMemoryError 发生内存溢出将堆信息转存起来 以便分析
-XX:HeapDumpPath为转存位置 生成的文件使用JProfiler 打开 分析
也可以在内存溢出时执行脚本 比如发送邮件给系统管理员脚本
-XX:OnOutOfMemoryError ="sh ~/cleanup.sh"
内存分配参数
-Xmx -Xms 堆的最大内存和最小内存(最小内存为初始内存 ，如果满了将不断扩容到最大内存)默认是物理内存的1/64
-Xmx20m -Xms20m 则固定堆空间为20m(年轻代+老年代)
-XX:SurvivorRatio Survivor(from-to)区和eden区的占比
例如 -XX:SurvivorRatio=5 则是5:1：1
-XX:SurvivorRatio=8:则是8:1:1
2560*(2/7) 则是from和to的大小 剩下则是eden区的大小
-XMmn 设置新生代的大小 (绝对值)
如 -Xmn2m 则设置新生为2m
-XX:NewRatio 新生代占老年代的比例
如果是4 则是1:4 如果是5则为1:5
如：
虽然新生代空间为2m但是2m通过计算eden和from to的的空间 但是真实新生代则是 eden+from或者to
-XX:PermSize -XX：MaxPermSize 设置永久代的值和最大值
因为jdk8之后溢出了永久代 使用元空间代替
MaxMetaspaceSize 元空间大小受制于操作系统内存
官方推荐堆空间内存分配
新生代占堆的3/8 幸存代占新生代的1/10
栈空间内内存分配
-Xss
栈空间是保存变量的地址 所以栈空间的大小决定了方法调用的深度 。比如递归方法会产生大量的变量
设置栈大小为108k 运行 几秒后栈溢出
则报栈溢出
我们如果我们将参数改为10m 则会等很久才会内存溢出