outOfMemeoryError处理
?
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
? ? ?已分配的 被引用的对象?
?
