JVM理论（一）：内存溢出调查（1）

一、TOMCAT内存大小调整
Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个java虚拟机。JAVA程序启动时JVM都会分配一个初始内存和最大内存给这个应用程序。这个初始内存和最大内存在一定程度都会影响程序的性能。比如说在应用程序用到最大内存的时候，JVM是要先去做垃圾回收的动作，释放被占用的一些内存。所以想调整Tomcat的启动时初始内存和最大内存就需要向JVM声明，一般的JAVA程序在运行都可以通过中-Xms -Xmx来调整应用程序的初始内存和最大内存：这两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的80%。

Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。有以下几种方法可以选用：
第一种方法：
　　Windows下，在文件/bin/catalina.bat，Linux下，在文件/bin/catalina.sh的前面，增加如下设置：
　　JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'
　　需要把这个两个参数值调大。例如：
　　JAVA_OPTS='-Xms512m -Xmx2048m'
　　表示初始化内存为512MB，可以使用的最大内存为2048MB。
第二种方法：环境变量中设变量名：JAVA_OPTS 变量值：-Xms2048m -Xmx2048m（一致）
第三种方法：前两种方法针对的是bin目录下有catalina.bat的情况（比如直接解压的Tomcat等），但是有些安装版的Tomcat下没有catalina.bat，这个时候可以采用如下方法，当然这个方法也是最通用的方法：打开tomcatHome/bin/tomcat5w.exe，点击Java选项卡，然后将会发现其中有这么两项：Initial memory pool和Maximum memory pool Initial memory pool这个就是初始化设置的内存的大小。Maximum memory pool这个是最大内存的大小 设置完了就按确定然后再重启TOMCAT你就会发现tomcat中jvm可用的内存改变了

二、jvm配置（内存溢出解决方法）
Total memory：java虚拟机正在使用的已经从系统那里挖到的内存大小，也就是java虚拟机这个进程当时所占用的所有内存。如果在运行java的时候没有添加-Xms参数，那么，在java程序运行的过程的，内存总是慢慢的从操作系统那里挖的，基本上是用多少挖多少，直到挖到maxMemory()为止，所以totalMemory()是慢慢增大的。如果用了-Xms参数，程序在启动的时候就会无条件的从操作系统中挖 -Xms后面定义的内存数，然后在这些内存用的差不多的时候，再去挖。 
Max memory：java虚拟机能够从操作系统那里挖到最大内存大小，如果在运行java程序的时候，没有添加-Xmx参数，那么默认就是64M，这是java虚拟机默认情况下能从操作系统那里挖到的最大的内存。如果添加了-Xmx参数，将以这个参数后面的值为准，建议设为内存的一半。 
Free memory：刚才讲到如果在运行java的时候没有添加-Xms参数，那么在java程序运行的过程中内存总是慢慢的从操作系统那里挖的，基本上是用多少挖多少，这些挖过来而又没有用上的内存，实际上就是free Memory，所以free Memory的值一般情况下都是很小的，但是如果你在运行java程序的时候使用了-Xms，这个时候因为程序在启动的时候就会无条件的从操作系统中挖-Xms后面定义的内存数，这个时候，挖过来的内存可能大部分没用上，所以这个时候freeMemory可能会有些大。
set JAVA_OPTS=-server -Xms1024m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m 
-server：一定要作为第一个参数，在多个CPU时性能佳 
-Xms：初始Heap大小，使用的最小内存，cpu性能高时此值应设的大一些 
-Xmx：java heap最大值，使用的最大内存 
-XX:PermSize：设定内存的永久保存区域 
-XX:MaxPermSize：设定最大内存的永久保存区域 
-XX:MaxNewSize：年轻代最大值，JVM堆区域新生代内存的最大可分配大小(PermSize不属于堆区)。
+XX:AggressiveHeap 会使得 Xms没有意义。这个参数让jvm忽略Xmx参数，疯狂地吃完一个G物理内存，再吃尽一个G的swap。 
-Xss：每个线程的Stack大小 
-verbose:gc：现实垃圾收集信息 
-Xloggc:gc.log：指定垃圾收集日志文件 
-Xmn：young generation的heap大小，一般设置为Xmx的3、4分之一 
-XX:+UseParNewGC：缩短minor收集的时间 
-XX:+UseConcMarkSweepGC：缩短major收集的时间提示：此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适。

tomcat的jvm内存溢出问题的解决
1、首先是：java.lang.OutOfMemoryError: Java heap space 
解释：
JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。 提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。提示：Heap Size最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
解决方法：
手动设置Heap size 修改TOMCAT_HOME/bin/catalina.bat，在“echo ”Using 
CATALINA_BASE: $CATALINA_BASE””上面加入以下行： set JAVA_OPTS=%JAVA_OPTS% 
-server -Xms1024m -Xmx1024m -XX:MaxNewSize=512m

2、其次是：java.lang.OutOfMemoryError: PermGen space 
原因：
PermGen space的全称是Permanent Generation space，是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的，Class在被Loader时就会被放到PermGen 
space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
解决方法：
明显可以看出是老年代的内存溢出，说明在容器下的静态文件过多，比如编译的字节码，jsp编译成servlet或者jar包。
手动设置MaxPermSize大小 
修改TOMCAT_HOME/bin/catalina.bat（Linux下为catalina.sh），在“echo ”Using 
CATALINA_BASE: $CATALINA_BASE””上面加入以下行： set JAVA_OPTS=%JAVA_OPTS% 
-server -XX:PermSize=128M -XX:MaxPermSize=512m
jvm内存参数
-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M
-vmargs 说明后面是VM的参数，所以后面的其实都是JVM的参数了
-Xms128m JVM初始分配的堆内存
-Xmx512m JVM最大允许分配的堆内存，按需分配
-XX:PermSize=64M JVM初始分配的非堆内存
-XX:MaxPermSize=128M JVM最大允许分配的非堆内存，按需分配

三、JVM年轻代（young generation）老年代（old generation tenured）持久代（permanent generation）GC
虚拟机中的内存共划分为三个代：年轻代（Young Generation）、老年代（Old Generation）和持久代（Permanent Generation）。其中持久代主要存放的是Java类的类信息，与垃圾收集要收集的Java对象关系不大。年轻代和年老代的划分是对垃圾收集影响比较大的。
1、年轻代:
所有新生成的对象首先都是放在年轻代里。年轻代的目标就是尽可能快速的收集那些生命周期短的对象。年轻代分三个区。一个Eden区，两个Survivor区(一般而言)。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor过来的对象。而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。
2、年老代:
在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
3、持久代:
用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置。
4、Scavenge GC
一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。
5、Full GC
对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC：
· 年老代（Tenured）被写满
· 持久代（Perm）被写满
· System.gc()被显示调用
·上一次GC之后Heap的各域分配策略动态变化

堆(Heap)和非堆(Non-heap)内存
按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在 Java 虚拟机启动时创建的。”
“在JVM中堆之外的内存称为非堆内存(Non-heap memory)”。
可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给自己用的

反思
1、GC有很多类型，这里讲的太粗了。
2、线上出现内存问题时的调试手段有哪些。

_已转移