\(^_^)/ Java 异常

 

java.lang.UnsupportedClassVersionError

 

 

java.lang.UnsupportedClassVersionError: com/ui/Test : Unsupported major.minor version 51.0
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
    at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:303)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
Exception in thread "main" 

 

 

程序编译的时候用了一个较高版本的JDK,但是在程序运行的时候却用了一个较低版本的jdk。

 

在eclipse里面先用jdk1.7将程序跑了一遍，然后用jdk1.6跑程序就会出现上述的错误，原因就是在用jdk1.7跑了程序没有问题，这时候在工程的bin目录下面就产生了相应于jdk1.7的class文件，下次再用jdk1.6跑这个工程，由于class文件是有jdk1.7产生的，所以程序跑不通也不足为奇！ 

 

解决的方法就是在第一次跑这个工程的时候用用较低版本的jdk,然后再用较高版本的jdk跑或者是一直用较高版本的jdk跑。也就是JDK较高版本兼容较低版本、但是较低版本却是无法完成较高版本的功能。这也是符合逻辑的。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

java.lang.OutOfMemoryError分析

 

 

 

1、OOM for Heap=>例如：java.lang.OutOfMemoryError: Java heap space
【分析】
 此OOM是由于JVM中heap的最大值不满足需要，将设置heap的最大值调高即可，参数样例为：-Xmx2G
【解决方法】
调高heap的最大值，即-Xmx的值调大。

2、OOM for Perm=>例如：java.lang.OutOfMemoryError: Java perm space
【分析】
 此OOM是由于JVM中perm的最大值不满足需要，将设置perm的最大值调高即可，参数样例为：-XX:MaxPermSize=512M
【解决方法】
调高heap的最大值，即-XX:MaxPermSize的值调大。
另外，注意一点，Perm一般是在JVM启动时加载类进来，如果是JVM运行较长一段时间而不是刚启动后溢出的话，
很有可能是由于运行时有类被动态加载进来，此时建议用CMS策略中的类卸载配置。
如：-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled

3、OOM for GC=>例如：java.lang.OutOfMemoryError: GC overhead limit exceeded
【分析】
此OOM是由于JVM在GC时，对象过多，导致内存溢出，建议调整GC的策略，在一定比例下开始GC而不要使用默认的策略，或者将新代和老代设置合适的大小，
需要进行微调存活率。
【解决方法】
改变GC策略，在老代80%时就是开始GC，并且将-XX:SurvivorRatio（-XX:SurvivorRatio=8）和-XX:NewRatio（-XX:NewRatio=4）设置的更合理。

4、OOM for native thread created=>例如：java.lang.OutOfMemoryError: unable to create new native thread
【分析】
参考如下：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads 
MaxProcessMemory   指的是一个进程的最大内存
JVMMemory         JVM内存
ReservedOsMemory   保留的操作系统内存
ThreadStackSize      线程栈的大小
如果JVM内存调的过大或者可利用率小于20%，可以建议将heap及perm的最大值下调，并将线程栈调小，即-Xss调小，如：-Xss128k
【解决方法】
在JVM内存不能调小的前提下，将-Xss设置较小，如：-Xss:128k

5、OOM for allocate huge array=>例如：Exception in thread "main": java.lang.OutOfMemoryError: Requested array size exceeds VM limit 
【分析】
此类信息表明应用程序（或者被应用程序调用的APIs）试图分配一个大于堆大小的数组。例如，如果应用程序new一个数组对象，大小为512M，但是最大堆大小为256M，因此OutOfMemoryError会抛出，因为数组的大小超过虚拟机的限制。
【解决方法】
（1）、首先检查heap的-Xmx是不是设置的过小
（2）、如果heap的-Xmx已经足够大，那么请检查应用程序是不是存在bug，例如：应用程序可能在计算数组的大小时，存在算法错误，导致数组的size很大，从而导致巨大的数组被分配。

 6、 OOM for small swap=>例如：Exception in thread "main": java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space? 
 【分析】
 抛出这类错误，是由于从native堆中分配内存失败，并且堆内存可能接近耗尽。这类错误可能跟应用程序没有关系，例如下面两种原因也会导致错误的发生：
（1）操作系统配置了较小的交换区
（2）系统的另外一个进程正在消耗所有的内存
 【解决方法】
（1）、检查os的swap是不是没有设置或者设置的过小
（2）、检查是否有其他进程在消耗大量的内存，从而导致当前的JVM内存不够分配。
注意：虽然有时<reason>部分显示导致OOM的原因，但大多数情况下，<reason>显示的是提示分配失败的源模块的名称，所以有必要查看日志文件，如crash时的hs文件。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 java.lang.OutOfMemoryError

 

 

 

这里以tomcat环境为例，其它WEB服务器如jboss,weblogic等是同一个道理。
一、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)那么就会产生此错误信息了。
解决方法： 手动设置MaxPermSize大小

修改TOMCAT_HOME/bin/catalina.sh
在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以达到减少jar 文档重复占用内存的目的。

二、java.lang.OutOfMemoryError: Java heap space
Heap size 设置
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.sh
在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -Xms800m -Xmx800m   -XX:MaxNewSize=256m"

三、实例，以下给出1G内存环境下java jvm 的参数设置参考：

JAVA_OPTS="-server -Xms800m -Xmx800m  -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "

四 相关资料

Java虚拟机的选项

Mac OS X的Java虚拟机除了具有标准的HotSpot虚拟机的选项之外，还支持很多非标准的选项（-X和-XX），本章列出了这些选项以及一些值得注意的例外事项。

 

请注意： 除非特别声明，否则在一个选项中指定的bytes（字节）都是作为参数。您也可以分别通过k或者m这两个字母来指定千个字节或者兆个字节(大小写都可以）。例如，下面的几种形式都是表示字节数：4194301，4096k，4096K，4m，和4M。

 

一般选项 

-server

在Mac OS X中没有特别的服务器虚拟机（server VM）。在激活java的时候可以使用 -server 选项，但这并不是启动另外的虚拟机，它还是启动客户虚拟机（client VM），只是这个虚拟机针对服务器的使用环境进行了调优。这些调优包括：

• 在共享档案的生成过程中使用不同的类列表，这个列表中不包括GUI类（见“Mac OS X的Java共享档案”部分）。 
  
• 增加Java堆的尺寸。 
  
• 增加Eden代的内存空间的尺寸。 
  
• 打开线程的本地Eden垃圾收集器（garbage collection）。 
  

-X

显示一个非标准虚拟机选项的简要描述。 

-Xbootclasspath:path

指定一个目录以及JAR和ZIP档案的列表，作为搜索启动类的范围。列表中各项之间的分隔符为冒号（:）。 

-Xfuture

对类文件执行严格的格式检查。这个选项强制Java对是否遵守类文件规范做更加严格的检查，而缺省的检查只是基于Java 1.1.x的标准。您应该使用这个选项来对代码进行测试，以便确保这些代码在未来的Java版本中能够工作，这些未来的版本可能强制进行更为严格的类文件格式检查。 

-Xprof

把运行程序详细的行为分析数据发送给标准输出。在产品级的代码中不能使用这个选项。 

-Xrs

和-XX:+ReduceSignalUsage选项一样。 

-XX:+ReduceSignalUsage

正常情况下，Java响应SIGHUP，SIGINT，和SIGTERM信号。如果指定了这个选项，则Java会忽略这些信号，您要根据具体的需要在本地代码中实现这些信号的处理函数，同时还要在System.exit()中实现相关的关闭例程。 

-XX:ReservedCodeCacheSize=size in bytes

设置最大的代码缓存的大小，缺省情况下是32（32M）。 

-XX:-PrintJavaStackAtFatalState

缺省情况下，当本地代码崩溃时，Java会产生回溯（backtraces）信息。如果您在Java的错误报告中看到了崩溃的信息，则可以把这个选项关闭。

Mac OS X 专用选项 

-Xdock:name=applicationName

设定应用程序在Dock和菜单条上显示的名称。如果这个选项没有被设定，则缺省情况下Mac OS X会显示主类的全名。您只需要对那些从命令行或者JAR文件中启动的程序设定这个选项，那些可以双击的应用程序包则从Info.plist文件中读取正确的显示名。 

-XX:+UseFileLocking

这个选项用来激活Carbon文件的锁定功能，缺省情况下关闭。如果您的Java应用程序和一些文件相互作用，而这些文件同时又受到一些Carbon应用程序的影响，则您需要使用这个选项，它可以避免应用程序修改那些正在被别的程序访问的文件。

堆的尺寸 

-Xmssize in bytes

设定Java堆的初始尺寸，缺省尺寸是2097152 (2MB)。这个值必须是1024个字节（1KB）的倍数，且比它大。（-server选项把缺省尺寸增加到32M。） 

-Xmnsize in bytes

为Eden对象设定初始Java堆的大小，缺省值为640K。（-server选项把缺省尺寸增加到2M。) 

-Xmxsize in bytes

设定Java堆的最大尺寸，缺省值为64M，（-server选项把缺省尺寸增加到128M。） 最大的堆尺寸达到将近2GB（2048MB）。

 

请注意：很多垃圾收集器的选项依赖于堆大小的设定。请在微调垃圾收集器使用内存空间的方式之前，确认是否已经正确设定了堆的尺寸。

 

垃圾收集:内存的使用 

-XX:MinHeapFreeRatio=percentage as a whole number

修改垃圾回收之后堆中可用内存的最小百分比，缺省值是40。如果垃圾回收后至少还有40%的堆内存没有被释放，则系统将增加堆的尺寸。 

-XX:MaxHeapFreeRatio=percentage as a whole number

改变垃圾回收之后和堆内存缩小之前可用堆内存的最大百分比，缺省值为70。这意味着如果在垃圾回收之后还有大于70%的堆内存，则系统就会减少堆的尺寸。 

-XX:NewSize=size in bytes

为已分配内存的对象中的Eden代设置缺省的内存尺寸。它的缺省值是640K。（-server选项把缺省尺寸增加到2M。） 

-XX:MaxNewSize=size in bytes

允许您改变初期对象空间的上限，新建对象所需的内存就是从这个空间中分配来的，这个选项的缺省值是640K。（-server选项把缺省尺寸增加到2M。） 

-XX:NewRatio=value

改变新旧空间的尺寸比例，这个比例的缺省值是8，意思是新空间的尺寸是旧空间的1/8。 

-XX:SurvivorRatio=number

改变Eden对象空间和残存空间的尺寸比例，这个比例的缺省值是10，意思是Eden对象空间的尺寸比残存空间大survivorRatio+2倍。 

-XX:TargetSurvivorRatio=percentage

设定您所期望的空间提取后被使用的残存空间的百分比，缺省值是50。 

-XX:MaxPermSize=size in MB

长久代（permanent generation）的尺寸，缺省值为32（32MB）。

垃圾收集: 一般设定 

-Xincgc

Mac OS X不支持这个选项，不支持这种训练式的垃圾收集器。 

-Xnoclassgc

禁用类的垃圾收集。 

-XX:+UseConcMarkSweepGC

激活标志和清除同时进行的垃圾收集活动，这个选项对多处理器的计算机有效。 

-XX:+UseParallelGC

激活并行的垃圾收集活动，这个选项只对多处理器的计算机有效。 

-XX:-DisableExplicitGC

忽略代码中对System.gc()的显式调用。虚拟机仍然按照正常的机制进行垃圾收集。这个选项禁止在代码中强制执行垃圾收集。 

-XX:+PrintTenuringDistribution

打印初期代中已分配内存的对象占用内存时间的信息。

编译 

-Xint

只在解释（interperated）模式下运行虚拟机。如果使用这个选项，系统将不编译任何字节码。 

-XX:CompileThreshold=value

在编译开始前改变方法调用（程序分支）的数目，缺省值是1000。 

-XX:-InlineUnreachableCalls

缺省情况下，虚拟机对所有可能的代码进行方法内联处理（method inlining）,以方便编译器进行优化。对这个选项进行设定会使较少的代码按照内联方法被编译。这样，那些正常情况下不会运行的代码，如例外处理，就不会被处理为内联代码，而只能在运行时进行解释。设定这个选项可能会大大降低性能。 

-XX:+CITime

显示有多少时间花在编译过的代码上。 

-XX:+PrintCompilation

在Java的方法被编译时，打印其的跟踪信息。

Threading 

-XX:NewSizeThreadIncrease=size in KB

允许您指定每个活动线程会增加多少初期对象空间。这个选项在调节由于线程增加而增加的分配率时可能会有用。它的缺省值为16（16 kilobytes）。 

-XX:ThreadStackSize=size in KB

改变线程栈的大小。缺省情况下，线程栈的大小就是操作系统所使用的栈的缺省大小。 

-XX:+UseTLAB

激活线程本地的分配缓冲区。 使用这个缓冲区将使线程任务繁重的应用程序的内存分配更加具有可扩展性，大大提高内存分配的性能。这个选项在多处理器的计算机和Mac OS X Server上缺省打开。

共享 

-XX:+PrintSharedSpace

打开共享的冗长输出。 

-XX:-UseSharedSpaces

关闭共享。

JVM垃圾回收机制在PDM系统中的应用

1.JVM的gc概述
   
    gc即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。不过常用的jvm都有gc，而且大多数gc都使用类似的算法管理内存和执行收集操作。
   
    在充分理解了垃圾收集算法和执行过程后，才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如，实时应用程序主要是为了避免垃圾收集中断，而大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和jvm支持的垃圾收集算法，便可以进行优化配置垃圾收集器。
   
    垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。gc首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。
   
    1.1.引用计数
    引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，jvm必须适当增减引用数。当某对象的引用数为0时，便可以进行垃圾收集。
   
    1.2.对象引用遍历
    早期的jvm使用引用计数，现在大多数jvm采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，gc必须记住哪些对象可以到达，以便删除不可到达的对象，这称为标记（marking）对象。
   
    下一步，gc要删除不可到达的对象。删除时，有些gc只是简单的扫描堆栈，删除未标记的未标记的对象，并释放它们的内存以生成新的对象，这叫做清除（sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多gc可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。
   
    为此，gc需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有gc运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的 gc不断增加或同时运行以减少或者清除应用程序的中断。有的gc使用单线程完成这项工作，有的则采用多线程以增加效率。
   
    2.几种垃圾回收机制
   
    2.1.标记－清除收集器
    这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。
   
    2.2.标记－压缩收集器
    有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。
   
    2.3.复制收集器
    这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，jvm生成的新对象则放在另一半空间中。gc运行时，它把可到达对象复制到另一半空间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
   
    2.4.增量收集器
    增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。
   
    2.5.分代收集器
    这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。jvm生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。
   
    2.6.并发收集器
    并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时）一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。
   
    2.7.并行收集器
    并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。
   
    3.Sun HotSpot 1.4.1 JVM堆大小的调整
   
    Sun HotSpot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便获得使用期并进入旧域。在永久域中jvm则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。
   
    下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。
    下面的命令是把初始大小设置为128M：
    java –Xms128m
    –Xmx256m为控制新域的大小，可使用-XX:NewRatio设置新域在堆中所占的比例。
   
    下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：
    java –Xms128m –Xmx128m
    –XX:NewRatio =3可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。
   
    下面的命令把新域的初始值和最大值设置成64m:
    java –Xms256m –Xmx256m –Xmn64m
    永久域默认大小为4m。运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。
   
    使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小。为了避免调整，可使用-XX:PerSize标志设置初始值。
    下面把永久域初始值设置成32m，最大值设置成64m。
    java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m
   
    默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio可控制新域子空间的大小。
   
    同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：
    java -Xms256m -Xmx256m -Xmn64m -XX:SurvivorRation =2
   
    如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以立即把它们移进旧域，避免在救助空间反复复制。但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。为控制新域中对象的复制，可用-XX:TargetSurvivorRatio控制救助空间的比例（该值是设置救助空间的使用比例。如救助空间位1M，该值50表示可用500K）。该值是一个百分比，默认值是50。当较大的堆栈使用较低的 sruvivorratio时，应增加该值到80至90，以更好利用救助空间。用-XX:maxtenuring threshold可控制上限。
   
    为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0。设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：
    java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝50000 …
   
    4.BEA JRockit JVM的使用
    Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是 Bea新JVM所在目录。不同于HotSpot把Java字节码编译成本地码，它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立的GUI控制台（只能适用于使用Jrockit才能使用jrockit81sp1_141_03自带的console监控一些cpu及 memory参数）或者WebLogic Server控制台。
   
    Bea JRockit JVM支持4种垃圾收集器：
    4.1.1.分代复制收集器
    它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery。这种收集器最适合单cpu机上小型堆操作。
   
    4.1.2.单空间并发收集器
    该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。
   
    分代并发收集器这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需要较少的内存，应用程序的运行效率也较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。
   
    4.1.3.并行收集器
    该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。
   
    默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc:<gc_name>，对应四个收集器分别为gencopy， singlecon，gencon以及parallel。可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用-Xns:java –jrockit –Xms512m –Xmx512m –Xgc:gencon –Xns128m…尽管JRockit支持-verbose:gc开关，但它输出的信息会因收集器的不同而异。JRockit还支持memory、 load和codegen的输出。
   
    注意 ：如果 使用JRockit JVM的话还可以使用WLS自带的console（C:\bea\jrockit81sp1_141_03\bin下）来监控一些数据，如cpu， memery等。要想能构监控必须在启动服务时startWeblogic.cmd中加入－Xmanagement参数。
   
    5.如何从JVM中获取信息来进行调整
   
    -verbose.gc开关可显示gc的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。打开- xx:+ printgcdetails开关，可以详细了解gc中的变化。打开-XX: + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自jvm启动以后以秒计量。最后，通过-xx: + PrintHeapAtGC开关了解堆的更详细的信息。为了了解新域的情况，可以通过-XX:=PrintTenuringDistribution开关了解获得使用期的对象权。
   
    6.Pdm系统JVM调整
   
    6.1.服务器：前提内存1G 单CPU
   
    可通过如下参数进行调整：－server 启用服务器模式（如果CPU多，服务器机建议使用此项）
   
    －Xms,－Xmx一般设为同样大小。 800m
    －Xmn 是将NewSize与MaxNewSize设为一致。320m
    －XX:PerSize 64m
    －XX:NewSize 320m 此值设大可调大新对象区，减少Full GC次数
    －XX:MaxNewSize 320m
    －XX:NewRato NewSize设了可不设。4
    －XX: SurvivorRatio 4
    －XX:userParNewGC 可用来设置并行收集
    －XX:ParallelGCThreads 可用来增加并行度 4
    －XXUseParallelGC 设置后可以使用并行清除收集器
    －XX：UseAdaptiveSizePolicy 与上面一个联合使用效果更好，利用它可以自动优化新域大小以及救助空间比值
   
    6.2.客户机：通过在JNLP文件中设置参数来调整客户端JVM
   
    JNLP中参数：initial-heap-size和max-heap-size
   
    这可以在framework的RequestManager中生成JNLP文件时加入上述参数，但是这些值是要求根据客户机的硬件状态变化的（如客户机的内存大小等）。建议这两个参数值设为客户机可用内存的60％（有待测试）。为了在动态生成JNLP时以上两个参数值能够随客户机不同而不同，可靠虑获得客户机系统信息并将这些嵌到首页index.jsp中作为连接请求的参数。
   
    在设置了上述参数后可以通过Visualgc 来观察垃圾回收的一些参数状态，再做相应的调整来改善性能。一般的标准是减少fullgc的次数，最好硬件支持使用并行垃圾回收（要求多CPU）。

Hot Spot JVM5中的GC调优

 

引言
有JAVA开发经验的朋友们一定碰到过下面的这种情况,那就是自己所开发的应用运行了一段时间后其性能或者响应速度会有明显的降低.这是由多方面的原因造成的即有程序本身的优化问题,也有运行环境问题.此运行环境即包括硬件环境也包括软件环境.大多数人第一个能想到的解决方法是提升硬件的配置而忽略了程序本身的运行环境JVM也提供了比较多的调优选项.本文将重点描述利用JVM的一些选项对GC进行调优.

 

约定:
1.读者应具备一定JAVA的知识.

2.本文中的JVM选项均以SUN公司发布的HotSpot JVM 5为准（不过大多数的选项在JVM1.3,JVM1.4中也是可用的）.

3.以JAVA_HOME下demo/jfc/SwingSet2/SwingSet2.jar为例进行说明.

4.阅读本文需要一些关于GC的知识，可以到附录A中了解这些知识。

关键字:
JVM(java虚拟机),调优,GC(垃圾回收)

JVM GC调优
为了能够将JVM GC的调优能够使用在具体的实践当中,下面将利用若干个例子来说明GC的调优.
例1：Heap size 设置
JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
当在JAVA_HOME下demo/jfc/SwingSet2/目录下执行下面的命令。
java -jar -Xmn4m -Xms16m -Xmx16m SwingSet2.jar
系统输出为：
Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Image Fetcher 3" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space
除了这些异常信息外，还会发现程序的响应速度变慢了。这说明Heap size 设置偏小，GC占用了更多的时间，而应用分配到的执行时间较少。
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
将上面的命令换成以下命令执行则应用能够正常使用，且未抛出任何异常。
java -jar -Xmn4m -Xms16m -Xmx32m SwingSet2.jar
提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

例2：Young Generation（-Xmn）的设置
在本例中看一下Young Generation的设置不同将有什么现象发生。
假设将Young generation 的大小设置为4M ，即执行java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar，屏幕输出如下（节选）
[GC [DefNew: 3968K->64K(4032K), 0.0923407 secs] 3968K->2025K(32704K), 0.0931870 secs]
[GC [DefNew: 4021K->64K(4032K), 0.0356847 secs] 5983K->2347K(32704K), 0.0365441 secs]
[GC [DefNew: 3995K->39K(4032K), 0.0090603 secs] 6279K->2372K(32704K), 0.0093377 secs]
[GC [DefNew: 3992K->23K(4032K), 0.0057540 secs] 6325K->2356K(32704K), 0.0060290 secs]
[GC [DefNew: 3984K->27K(4032K), 0.0013058 secs] 6317K->2360K(32704K), 0.0015888 secs]
[GC [DefNew: 3981K->59K(4032K), 0.0023307 secs] 6315K->2422K(32704K), 0.0026091 secs]
将程序体制并将Young Generation的大小设置为8M，即执行java -jar -verbose:gc -Xmn8m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar，屏幕输出如下（节选）
[GC [DefNew: 7808K->192K(8000K), 0.1016784 secs] 7808K->2357K(32576K), 0.1022834 secs]
[GC [DefNew: 8000K->70K(8000K), 0.0149659 secs] 10165K->2413K(32576K), 0.0152557 secs]
[GC [DefNew: 7853K->59K(8000K), 0.0069122 secs] 10196K->2403K(32576K), 0.0071843 secs]
[GC [DefNew: 7867K->171K(8000K), 0.0075745 secs] 10211K->2681K(32576K), 0.0078376 secs]
[GC [DefNew: 7970K->192K(8000K), 0.0201353 secs] 10480K->2923K(32576K), 0.0206867 secs]
[GC [DefNew: 7979K->30K(8000K), 0.1787079 secs] 10735K->4824K(32576K), 0.1790065 secs]
那么根据GC输出的信息（这里取第一行）做一下Minor收集的比较。可以看出两次的Minor收集分别在Young generation中找回3904K（3968K->64K）和7616K(7808K->192K)而对于整个jvm则找回1943K（3968K->2025）和5451K（7808K->2357K）。第一种情况下Minor收集了大约50％（1943/3904）的对象，而另外的50％的对象则被移到了tenured generation。在第二中情况下Minor收集了大约72％的对象，只有不到30％的对象被移到了Tenured Generation.这个例子说明此应用在的Young generation 设置为4m时显的偏小。
提示：一般的Young Generation的大小是整个Heap size的1/4。Young generation的minor收集率应一般在70％以上。当然在实际的应用中需要根据具体情况进行调整。

例3：Young Generation对应用响应的影响
还是使用-Xmn4m 和-Xmn8m进行比较，先执行下面的命令

java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime SwingSet2.jar
屏幕输出如下（节选）
Application time: 0.5114944 seconds
[GC [DefNew: 3968K->64K(4032K), 0.0823952 secs] 3968K->2023K(32704K), 0.0827626 secs]
Total time for which application threads were stopped: 0.0839428 seconds
Application time: 0.9871271 seconds
[GC [DefNew: 4020K->64K(4032K), 0.0412448 secs] 5979K->2374K(32704K), 0.0415248 secs]
Total time for which application threads were stopped: 0.0464380 seconds
Young Generation 的Minor收集占用的时间可以计算如下：应用线程被中断的总时常/（应用执行总时?L+应用线程被中断的总时常），那么在本例中垃圾收集占用的时?L约为系统的5％~14％。那么当垃圾收集占用的时间的比例越大的时候，系统的响应将越慢。
提示：对于互联网应用系统的响应稍微慢一些，用户是可以接受的，但是对于GUI类型的应用响应速度慢将会给用户带来非常不好的体验。

例4：如何决定Tenured Generation 的大小
分别以-Xmn8m -Xmx32m和-Xmn8m -Xmx64m进行对比，先执行
java -verbose:gc -Xmn8m -Xmx32m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类，命令行将提示（只提取了Major收集）

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]
122.463: [GC 122.463: [DefNew: 8128K->8128K(8128K), 0.0000560 secs]122.463: [Tenured: 18630K->2366K(24576K), 0.1322560 secs] 26758K->2366K(32704K), 0.1325284 secs]
133.896: [GC 133.897: [DefNew: 8128K->8128K(8128K), 0.0000443 secs]133.897: [Tenured: 18240K->2573K(24576K), 0.1340199 secs] 26368K->2573K(32704K), 0.1343218 secs]
144.112: [GC 144.112: [DefNew: 8128K->8128K(8128K), 0.0000544 secs]144.112: [Tenured: 16564K->2304K(24576K), 0.1246831 secs] 24692K->2304K(32704K), 0.1249602 secs]
再执行java -verbose:gc -Xmn8m -Xmx64m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类，命令行将提示（只提取了Major收集）
90.597: [GC 90.597: [DefNew: 8128K->8128K(8128K), 0.0000542 secs]90.597: [Tenured: 49841K->5141K(57344K), 0.2129882 secs] 57969K->5141K(65472K), 0.2133274 secs]
120.899: [GC 120.899: [DefNew: 8128K->8128K(8128K), 0.0000550 secs]120.899: [Tenured: 50384K->2430K(57344K), 0.2216590 secs] 58512K->2430K(65472K), 0.2219384 secs]
153.968: [GC 153.968: [DefNew: 8128K->8128K(8128K), 0.0000511 secs]153.968: [Tenured: 51164K->2309K(57344K), 0.2193906 secs] 59292K->2309K(65472K), 0.2196372 secs]
可以看出在Heap size 为32m的时候系统等候时间约为0.13秒左右，而设置为64m的时候等候时间则增大到0.22秒左右了。但是在32m的时候系统的Major收集间隔为10秒左右，而Heap size 增加到64m的时候为30秒。那么应用在运行的时候是选择32m还是64m呢？如果应用是web类型（即要求有大的吞吐量）的应用则使用64m（即heapsize大一些）的比较好。对于要求实时响应要求较高的场合（例如GUI型的应用）则使用32m比较好一些。 
注意：
1。因为在JVM5运行时已经对Heap-size进行了优化，所以在能确定java应用运行时不会超过默认的Heap size的情况下建议不要对这些值进行修改。
2。Heap size的 -Xms -Xmn 设置不要超出物理内存的大小。否则会提示“Error occurred during initialization of VM Could not reserve enough space for object heap”。

例5:如何缩短minor收集的时间
下面比较一下采用-XX:+UseParNewGC选项和不采用它的时候的minor收集将有什么不同。先执行
java -jar -server -verbose:gc -Xmn8m -Xms32m -Xmx32m SwingSet2.jar 
系统将输出如下信息（片段〕
[GC 7807K->2641K(32576K), 0.0676654 secs]
[GC 10436K->3108K(32576K), 0.0245328 secs]
[GC 10913K->3176K(32576K), 0.0072865 secs]
[GC 10905K->4097K(32576K), 0.0223928 secs]
之后再执行 java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar
系统将输出如下信息（片段〕
[ParNew 7808K->2656K(32576K), 0.0447687 secs]
[ParNew 10441K->3143K(32576K), 0.0179422 secs]
[ParNew 10951K->3177K(32576K), 0.0031914 secs]
[ParNew 10985K->3867K(32576K), 0.0154991 secs]
很显然使用了-XX:+UseParNewGC选项的minor收集的时间要比不使用的时候优。

例6:如何缩短major收集的时间
下面比较一下采用-XX:+UseConcMarkSweepGC选项和不采用它的时候的major收集将有什么不同。先执行
java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar
系统将输出如下信息（片段〕
[Full GC 22972K->18690K(262080K), 0.2326676 secs]
[Full GC 18690K->18690K(262080K), 0.1701866 secs
之后再执行 java -jar -verbose:gc -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar
系统将输出如下信息（片段〕
[Full GC 56048K->18869K(260224K), 0.3104852 secs]
提示：此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适。

例7:关于-server选项 在JVM中将运行中的类认定为server-class的时候使用此选项。SUN 的Hot Spot JVM5 如果判断到系统的配置满足如下条件则自动将运行的类认定为server-class，并且会自动设置jvm的选项（当没有手工设置这选项的时候〕而且HOTSPOT JVM5提供了自动调优的功能，他会根据JVM的运行情况进行调整。如果没有特别的需要是不需要太多的人工干预的。SUN形象的称这个机制为“人体工学”（Ergonomics〕。具体可以参考http://java.sun.com/docs/hotspot/gc5.0/ergo5.html
*.具有2个或更多个物理的处理器
*.具有2G或者更多的物理内存
提示：此选项要放在所有选项的前面。例如：java -server 其他选项 java类

附录A:预备知识
．JVM中对象的划分及管理

JVM根据运行于其中的对象的生存时间大致的分为3种。并且将这3种不同的对象分别存放在JVM从系统分配到的不同的内存空间。这种对象存放空间的管理方式叫做Generation管理方式。
1。Young Generation：用于存放“早逝”对象（即瞬时对象）。例如：在创建对象时或者调用方法时使用的临时对象或局部变量。
2。Tenured Generation：用于存放“驻留”对象（即较长时间被引用的对象）。往往体现为一个大型程序中的全局对象或长时间被使用的对象。
3。Perm Generation：用于存放“永久”对象。这些对象管理着运行于JVM中的类和方法。

．JVM选项的分类

JVM有这么几种选项供使用.
1.供-X选项使用的项目,又称为非标准选项，不同厂商的此类型选项是有所不同的。例如：IBM的JVM用的一些选项在Sun的JVM中就不一定能生效。这种选项的使用方式如下:
java -Xmn16m -Xms64m -Xmx64m java类名
2.供-XX选项使用的项目，这种类型的选项可能要求有对系统信息访问的权限。所以要慎用。这种选项的使用方式如下:
java -XX:MaxHeapFreeRatio=70 -XX:+PrintGCDetails java类名
3.java选项(即在命令行执行java后提示的选项).
java -server -verbose:gc -d64 java类名

．垃圾收集分类

在JVM中有两种垃圾方式，一种叫做Minor（次收集），另一种叫做Major（主收集）。其中Minor在Young Generation的空间被对象全部占用后执行，主要是对Young Generation中的对象进行垃圾收集。而Major是针对于整个Heap size的垃圾收集。其中Minor方式的收集经常发生，并且Minor收集所占用的系统时间小。Major方式的垃圾收集则是一种“昂贵”的垃圾收集方式，因为在Major要对整个Heap size进行垃圾收集,这会使得应用停顿的时间变得较长。

．GC信息的格式

 

[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]
<collector> GC为minor收集过程中使用的垃圾收集器起的内部名称.
<starting occupancy1> young generation 在进行垃圾收集前被对象使用的存储空间.
<ending occupancy1> young generation 在进行垃圾收集后被对象使用的存储空间
<pause time1> minor收集使应用暂停的时间长短(秒) 
<starting occupancy3> 整个堆(Heap Size)在进行垃圾收集前被对象使用的存储空间
<ending occupancy3> 整个堆(Heap Size)在进行垃圾收集后被对象使用的存储空间
<pause time3> 整个垃圾收集使应用暂停的时间长短(秒),包括major收集使应用暂停的时间(如果发生了major收集).
．GC信息的选项
-XX:+PrintGCDetails 显示GC的详细信息
-XX:+PrintGCApplicationConcurrentTime 打印应用执行的时间
-XX:+PrintGCApplicationStoppedTime 打印应用被暂停的时间
提示:1.":"后的"+"号表示开启此选项,如果是"-"号那么表示关闭此选项。
     2.在不同的选项和不同的收集方式和类型下输出的格式会有所不同。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

在跟踪性能问题时，堆内存是首先应该被监控的最重要的组件之一。一旦堆内存的实际使用量超过其所允许的堆空间，就会产生堆内存压力。而这将导致频繁的全面垃圾回收事件，垃圾回收将窃取CPU周期，轻则导致响应时间延迟，重则导致必须重新启动Java虚拟机才能解决的内存溢出错误。

内存溢出错误（OOM）
当我运行应用时，出现了如下异常：

• java.lang.OutOfMemoryError: GC overhead limit exceeded[7,9]
• java.lang.OutOfMemoryError: Java heap space

第一条信息意味着，出于某种原因，垃圾收集器每次执行都花费了大量时间但只回收了很少量的内存，当我删除了如下代码后：

1	System.gc();

第一条信息消失了，取而代之的，系统出现了第二条信息。很明显堆内存空间依然存在问题。下面是我调查问题的步骤：

1. 添加下面的Java启动参数分析日志文件:
   • -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
     • 系统会生成gc.log文件
   • -XX:+HeapDumpOnOutOfMemoryError
     • 系统会生成堆内存转储文件

• 使用常规的文本编辑器查看gc.log 文件。
• 使用 Eclipse Memory Analyzer 查看 堆内存转储文件 (例如, java_xxx.hprof)

请注意，本文所讨论的所有虚拟机参数都是基于Hotspot虚拟机的。

Java命令行参数说明:

• -XX:+PrintGCDetails
  • 打印更多的关于垃圾收集的信息。
• -XX:+PrintGCTimeStamps
  • 打印从HotSpot 虚拟机开始执行直至垃圾收集事件发生所花费的时间（以秒为单位）。
• -Xloggc:gc.log
  • 在每次垃圾收集时打印堆内存以及垃圾收集的信息。

在JDeveloper中可以按照如下方式设定：

1. 右键选择你的项目（例如ViewController），显示出菜单
2. 选择Project Properties…
3. 选择Run/Debug/Profile
4. 选择你Run Configuration(例如, Default)
5. 点击Edit按钮
6. 在Java虚拟机参数栏位设定 -Xloggc:gc.log -XX:-PrintGCDetails

 

 

 

运行你的应用并重现内存溢出异常，系统将会生成日志文件gc.log，
我的是在如下目录：

• …/system11.1.1.5.37.60.13/DefaultDomain

因为我的Web应用是部署在集成的WLS中，并且通过DefaultDomain来执行。
所以，想要理解gc.log文件的格式，请参考关联阅读[5,15]。

不过，gc.log文件并不能真正的帮到我们，因为他只是简要的打印了堆内存问题，

但并没有指出问题出在哪。
接下来我要做的是添加如下参数，并重新执行服务。
-XX:+HeapDumpOnOutOfMemoryError
当服务发生堆内存错误时，会生成java_pid30835.hprof文件。

 Eclise内存分析器（Eclipse Memory Analyzer）

堆内存转储文件由HPROF（堆内存和CPU分析工具）生成，堆内存转储文件是2进制格式的，因此必须使用Eclpse Memory Analyzer 来查看。

你可以通过Eclipse Update manager 来安装Eclipse MAT，选择”General Purpose Tools “并安装”Memory Analyser (Incubation)”以及”Memory Analyser (Charts)”。

 

安装之后，双击堆内存转储文件并且选择”Leak Suspects Report”

 

Eclipse MAT会显示如下图表：

 

以及问题的嫌疑人：

 

 

调整堆内存空间

如果你观察到垃圾收集日志文件中有内存溢出错误，那么可以尝试将Java堆内存空间调整为你能够分配给Java虚拟机的物理内存空间的80%，基于具体是老年代空间还是永久代空间发生内存溢出，你可以像这样调整内存空间。

 

• 针对老年代发生内存溢出
  • increase -Xms and -Xmx
• 针对永久代发生内存溢出
  • increase -XX:PermSize and -XX:MaxPermSize

 

 

 

 

 

 

 

 

 

 

 

 

 

 

原因：
常见的有以下几种：

1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；

2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；

3.代码中存在死循环或循环产生过多重复的对象实体；

4.使用的第三方软件中的BUG；

5.启动参数内存值设定的过小；

 

常见错误提示：
1.tomcat:java.lang.OutOfMemoryError: PermGen space

2.tomcat:java.lang.OutOfMemoryError: Java heap space

3.weblogic:Root cause of ServletException java.lang.OutOfMemoryError

4.resin:java.lang.OutOfMemoryError

5.java:java.lang.OutOfMemoryError

 

 

解决；
1.应用服务器提示错误的解决：
把启动参数内存值设置足够大。

 

2.Java代码导致错误的解决：
重点排查以下几点：

1)检查代码中是否有死循环或递归调用。

2)检查是否有大循环重复产生新对象实体。

3)检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

4 )检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

 

 

tomcat中java.lang.OutOfMemoryError: Java heap space异常处理

一、Heap size 
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.sh
在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -Xms800m -Xmx800m   -XX:MaxNewSize=256m"

 

 

tomcat中java.lang.OutOfMemoryError: PermGen space异常处理

一、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)那么就会产生此错误信息了。

解决方法： 手动设置MaxPermSize大小
修改TOMCAT_HOME/bin/catalina.sh
在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以达到减少jar 文档重复占用内存的目的。

 

 

weblogic中java.lang.OutOfMemoryError异常处理

错误提示：
"Root cause of ervletException java.lang.OutOfMemoryError"

解决办法：
调整bea/weblogic/common中CommEnv中参数
　　 :sun
　　if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode
　　set JAVA_VM=-client
　　set MEM_ARGS=-Xms256m -Xmx512m -XX:MaxPermSize=256m
　　set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none
　　goto continue
　　:sun_prod_mode
　　set JAVA_VM=-server
　　set MEM_ARGS=-Xms256m -Xmx512m -XX:MaxPermSize=256m
　　goto continue

 

 

 

 

 

Eclipse运行Jboss时java.lang.OutOfMemoryError：PermGen space异常处理

在Eclipse中运行Jboss时，时间太长可能有时候会出现java.lang.OutOfMemoryError：PermGen space的错误，这里给介绍大家一种解决方法：

1)点击debug图标旁边的小箭头；

2)点击”Debug Configurations…”菜单项；

3)选左边的“Generic Server”树下面的“JBoss v4.2 at localhost”；

4)点击右边的“Arguments”Tab页签，在“VM arguments”中添加：

-Dprogram.name=run.bat -Djava.endorsed.dirs="D:/JBoss405/bin/../lib/endorsed" -Xms128m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=256m

5)如果你是以命令行模式或者直接点击“run.bat”来运行JBoss，那你就要在 bin/run.conf 文件中对JVM选项作修改了，找到 JAVA_OPTS="-Xms128m -Xmx512m…” 这一段，然后在后面加上 “ -XX:PermSize=64m -XX:MaxPermSize=256m”。保存就OK了。

6)注意：其中128、512、64和256等数字可以根据自己机器的配置来做一些相应的调整，然后点击“Apply”就可以了。

 

 

Resin下java.lang.OutOfMemoryError异常处理

原因：
出现这个错误，一般是因为JVM物理内存过小。默认的Java虚拟机最大内存仅为64兆，这在开发调试过程中可能没有问题，但在实际的应用环境中是远远不能满足需要的，除非你的应用非常小，也没什么访问量。否则你可能会发现程序运行一段时间后包java.lang.OutOfMemoryError的错误。因此我们需要提升resin可用的虚拟机内存的大小。

解决：
修改/usr/local/resin/bin/httpd.sh中的args选项
添加参数-Xms（初始内存）和-Xmx（最大能够使用内存大小）
可以用来限制JVM的物理内存使用量。
例如：
args="-Xms128m -Xmx256m"
设置后，JVM初始物理内存是128m，最大能使用物理内存为256m。
这两个值应该由系统管理员根据服务器的实际情况进行设置。

案例：
1.hibernate查询数据时，一次查询过多的数据，后来调整了该部分的代码，每次只取出指定量的数据，成功的解决该问题。
2.在做压力测试时，出现OutOfMemoryError，发现session的资源一直没有被释放产生的，最好通过session的invalidate()方法将session的资源释放。
3.程序中出现死循环。
4.tomcat部署、运行出现OutOfMemoryError，加大内存参数值，解决此问题。