outOfMemeoryError处理

outOfMemeoryError处理（使用hprof）

1. 程序出现 

 

Exception in thread "pool-1-thread-2" java.lang.OutOfMemoryError: Java heap space

 

2. 找到是哪些 代码 导致出现了 这样的问题

 

3. 使用 

 

-Xrunhprof:heap=sites,depth=12 再次启动程序 

 

  <jvmarg  value="-Xrunhprof:heap=sites,depth=12"/>

  <xmlfileset refid="testng.conf"/>

</testng>

 

 

 

4.看生成的文件   java.hprof.txt  查看调用栈  TOP 10 的调用栈

 

 

 

298625           percent          live          alloc'ed  stack class

298626  rank   self  accum     bytes objs     bytes  objs trace name

298627     1 15.60% 15.60%   8400672 25002   8400672 25002 322798 char[]

298628     2  6.69% 22.29%   3600288 25002   3600288 25002 322771 org.testng.internal.TestNGMethod

298629     3  6.69% 28.98%   3600288 25002   3600288 25002 322805 org.testng.internal.ConfigurationMethod

298630     4  6.69% 35.67%   3600144 25001   3600144 25001 322882 org.testng.internal.ConfigurationMethod

298631     5  6.32% 41.98%   3400272 25002   3400272 25002 322822 char[]

298632     6  5.94% 47.92%   3200128 25001   3200128 25001 322896 char[]

298633     7  3.72% 51.64%   2000160 25002   2000160 25002 322799 org.testng.internal.NoOpTestClass

298634     8  2.60% 54.24%   1400112 25002   1400112 25002 322782 java.lang.Object[]

298635     9  2.60% 56.84%   1400112 25002   1400112 25002 322814 java.lang.Object[]

298636    10  2.60% 59.44%   1400112 25002   1400112 25002 322816 java.lang.Object[]

298637    11  2.60% 62.04%   1400056 25001   1400056 25001 322890 java.lang.Object[]

298638    12  2.60% 64.64%   1400056 25001   1400056 25001 322891 java.lang.Object[]

298639    13  2.60% 67.24%   1400056 25001   1400056 25001 323002 java.lang.Object[]

298640    14  2.23% 69.47%   1200072 50003   1200072 50003 322813 java.util.ArrayList

298641    15  2.23% 71.70%   1200072 50003   1200072 50003 322815 java.util.ArrayList

298642    16  2.23% 73.93%   1200048 25001   1200048 25001 323000 org.testng.internal.SingleTestMethodWorker

 

 

 

292945 TRACE 322771:

292946   org.testng.internal.BaseTestMethod.<init>(BaseTestMethod.java:89)

292947   org.testng.internal.BaseTestMethod.<init>(BaseTestMethod.java:85)

292948   org.testng.internal.TestNGMethod.<init>(TestNGMethod.java:46)

292949   org.testng.internal.TestNGMethod.clone(TestNGMethod.java:167)

292950   org.testng.internal.TestNGMethod.clone(TestNGMethod.java:25)

292951   org.testng.internal.Invoker.invokePooledTestMethods(Invoker.java:1430)

292952   org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1167)

292953   org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)

292954   org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)

292955   java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

292956   java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

292957   java.lang.Thread.run(Thread.java:662)

 

 

 

在 ： invokeTestMethods  方法中有如下  代码  ： 

由于本次代码的invocationCount  只是 1000000  太大 ，循环内部 每次都在创建 ITestResult testResult  这个对象导致内存溢出

 

while(invocationCount-- > 0) {

      boolean okToProceed = checkDependencies(testMethod, allTestMethods);

 

      if (!okToProceed) {

        //

        // Not okToProceed. Test is being skipped

        //

        ITestResult testResult = new TestResult(testClass, null /* instance */,

                                               testMethod,

                                               null /* cause */,

                                               start,

                                               System.currentTimeMillis(),

                                               m_testContext);

        String missingGroup = testMethod.getMissingGroup();

        if (missingGroup != null) {

          testResult.setThrowable(new Throwable("Method " + testMethod

              + " depends on nonexistent group \"" + missingGroup + "\""));

        }

 

        testResult.setStatus(ITestResult.SKIP);

        result.add(testResult);

        m_notifier.addSkippedTest(testMethod, testResult);

        runTestListeners(testResult);

        return result;

      }

 

 

解决办法 ，可以自己实现他的 线程调用，这样testng 中每次代码调用完成，就会 进行 GC 回收

 

 

 

 

 

hprof出处来源网址： http://www.cnblogs.com/linhaohong/archive/2012/07/12/2588657.html

J2SE中提供了一个简单的命令行工具来对java程序的cpu和heap进行 profiling，叫做HPROF。HPROF实际上是JVM中的一个native的库，它会在JVM启动的时候通过命令行参数来动态加载，并成为 JVM进程的一部分。若要在java进程启动的时候使用HPROF，用户可以通过各种命令行参数类型来使用HPROF对java进程的heap或者 （和）cpu进行profiling的功能。HPROF产生的profiling数据可以是二进制的，也可以是文本格式的。这些日志可以用来跟踪和分析 java进程的性能问题和瓶颈，解决内存使用上不优的地方或者程序实现上的不优之处。二进制格式的日志还可以被JVM中的HAT工具来进行浏览和分析，用 以观察java进程的heap中各种类型和数据的情况。

在J2SE 5.0以后的版本中，HPROF已经被并入到一个叫做Java Virtual Machine Tool Interface（JVM TI）中。

 

hprof使用来源网址： http://www.ms-accp.com/New-1346.html

 

java -Xrunhprof:heap=sites  -Xms4100m -Xmx4100m  -Djava.library.path=$LD_LIBRARY_PATH -classpath ./build/classes:./build/*:./conf:./lib/* com.yoyosys.yihualu.ehual    uImpl.StartYhl parser.properties

 

 

在执行命令的根目录 会生成  java.hprof.txt  这个文件 

当命令行 出现   一下字段 ，表示  该文件已经生成

 Dumping allocation sites ... done.

如果程序处于 停滞状态 ，使用 Ctrl+c  直接终止 ，运行 这一个文件也能够生成！

 

 

这部分的一个实例展示了我们怎样才能够运行装载在JDK 中的剖析器。尽管从剖析器而来

的消息是以略显粗糙的文本文件形式表示的，而不是像一般的商业剖析器那样产生图形化的

表示，但是在判定我们程序的特性方面，它仍然能够提供很有价值的帮助。

当我们调用程序时，通过向Java 虚拟机传送一个额外参数来运行剖析器。这个参数必须是

一个单一字符串，逗号后面没有任何空格，像这样（尽管它应该在一个单一的行中，但是在

书中被缠绕表示了，因为书页面不够宽）：

 

 

java

–Xrunhprof:heap=sites,cpu=samples,depth=10,monitor=y,thread=y,

doe=y ListPerformance

?? heap=sites 告知剖析器编写在堆上的内存使用信息，指示被分配在什么地方。

?? cpu=samples 告知剖析器进行统计抽样来确定CPU 的使用情况。

?? depth=10 指示线程追踪的深度(默认是4)。

?? thread=y 告诉剖析器去标识在堆栈序列中的线程。

?? doe=y 告知剖析器在退出时清空剖析数据。

下面的列表仅包含 HPROF 所产生的文件的一部分。输出文件被创建在当前目录下并且被命

名为java.hprof.txt。

java.hprof.txt 开始部分描述了文件中其余部分的细节。由剖析器产生的数据处于不同

部分；例如，TRACE 表示文件中的追踪部分。我们将会看到许多TRACE 部分，每个都编了

号，以便可以在后面进行引用。

SITES 部分展示了内存分配的位置。这部分有几行，它们按照被分配和被引用的字节（活

动着的字节）数排序。内存以字节列出。Self 列代表该位置占据内存的百分比，下一列

accum，代表累积的内存百分比。live bytes 和live objects 列代表在该位置上的活

动的字节数和所创建的、占用这些字节的对象个数。allocated bytes 和 objects 代

表实例的对象总数和字节总数，包括那些正在被使用的和没有被使用的。在allocated 和

live 中列出的字节数之差代表可以被垃圾收集的字节数。Trace 列实际上引用了文件中的

一个TRACE。第一行引用了下面显示的668 追踪。name 代表被创建实例所属的类。

SITES BEGIN (ordered by live bytes) Thu Jul 18 11:23:06 2002

percent live alloc'ed stack class

rank self accum bytes objs bytes objs trace name

1 59.10% 59.10% 573488 3 573488 3 668 java.lang.Object

2 7.41% 66.50% 71880 543 72624 559 1 [C

3 7.39% 73.89% 71728 3 82000 10 649 java.lang.Object

4 5.14% 79.03% 49896 232 49896 232 1 [B

5 2.53% 81.57% 24592 310 24592 310 1 [S

TRACE 668: (thread=1)

java.util.Vector.ensureCapacityHelper(Vector.java:222)

java.util.Vector.insertElementAt(Vector.java:564)

java.util.Vector.add(Vector.java:779)

java.util.AbstractList$ListItr.add(AbstractList.java:495)

ListPerformance$3.test(ListPerformance.java:40)

ListPerformance.test(ListPerformance.java:63)

ListPerformance.main(ListPerformance.java:93)

这个追踪展示了分配内存的方法调用序列。如果我们进入由行号所指示的追踪，我们将发现

有一个对象分配动作发生在 Vector.java 的222 行：

elementData = new Object[newCapacity];

这有助于我们发现程序中使用掉相当大的内存数量（在这种情形下是 59.10 %）的部分。

注意在位置 1 的[C 表示基本数据类型char。这是Java 虚拟机中对基本数据类型的内部

表示。

 

hprof来源网址： http://www.cnblogs.com/linhaohong/archive/2012/07/12/2588657.html

1.查看内存CPU使用情况

2.查看java内存分配信息   

 

1.java -agentlib:hprof=help  使用该命令可以得到 帮组说明和默认配置值

 

java -Xrunhprof:heap=sites  -Xms4100m -Xmx4100m  -Djava.library.path=$LD_LIBRARY_PATH -classpath ./build/classes:./build/*:./conf:./lib/* com.yoyosys.yihualu.ehual    uImpl.StartYhl parser.properties

 

 

 

将  java进程profiling的信息（sites和dump）都会被写入到一个叫做java.hprof.txt的文件中。大多数情况下，该文件中都会对每个trace，threads，objects包含一个ID，每一个ID代表一个不同的观察对象。通常，traces会从300000开始。

 

 

默认，force=y，会将所有的信息全部输出到output文件中，所以如果含有多个JVMs都采用的HRPOF enable的方式运行，最好将force=n，这样能够将单独的JVM的profiling信息输出到不同的指定文件。

 

interval选项只在 cpu=samples的情况下生效，表示每隔多少毫秒对java进程的cpu使用情况进行一次采集。

 

msa选项仅仅在Solaris系统下才有效，表示会使用Solaris下的Micro State Accounting功能

 

 

 

live

     存活的 被引用的对象

 

alloced

     已分配的 被引用的对象