http://www.docin.com/p-68079633.html  Tuxedo事务处理

在根(/)目录下提供一个遗失+查找(lost+found)系统

==============================================

（1）如果使用OracleJVM也就是标准的SUNJVM（SUN已被oracle收购）

当内存溢出时生成heapdump文件配置如下

-Xloggc:${目录}/temp_gc.log（GC日志文件）

-XX:HeapDumpPath=${目录}（heapdump文件存放位置）

如果要即时动态生成heapdump文件可以使用jmap命令，jdk6.0已取消了-XX:+HeapDumpOnCtrlBreak配置参数通过ctrl+break的方式。

-Xverbosegc:file=${目录}/temp_gc.log（GC日志文件）

-XX:+HeapDumpOnOutOfMemoryError（内存溢出时生成heapdump文件）

-XX:+HeapDumpOnCtrlBreak（可以通过ctrl+break组合键动态生成heapdump文件）

-XX:HeapDumpPath=${目录}（heapdump文件存放位置）

（3）IBMJVM

非windows操作系统环境中

-XverboseGClog:${目录}/temp_gc.log（GC日志文件）

-Xdump:heap:events=user,file=${目录}/pid%uid%pid.phd

表示可以根据需要通过kill-3<pid>产生DUMP文件，%uid和%pid为变量

windows操作系统环境中

启动wsadmin,进入wsadmin环境

PSYoungGen/PSOldGen/PSPermGen区别

SUNJVMGC使用是分代收集算法，即将内存分为几个区域，将不同生命周期的对象放在不同区域里.

新的对象会先生成在Youngarea，也就是PSYoungGen中

在几次ＧＣ以后，如过没有收集到，就会逐渐升级到PSOldGen及Tenuredarea(也就是PSPermGen)中。

三者区别：

在GC收集的时候，频繁收集生命周期短的区域(Youngarea)，因为这个区域内的对象生命周期比较短，GC效率也会比较高。而比较少的收集生命周期比较长的区域(OldareaorTenuredarea)，以及基本不收集的永久区(Permarea)。

==================================================

jvm调优总结http://www.open-open.com/lib/view/open1340100383299.html

阅读目录

探究JVM内存泄露性能调优的基本知识和JDK调优

1.1性能是什么

1.2调优的规则

1.3调优的步骤

2.1选择合适的JDK版本

2.2垃圾收集Java堆的优化

WEB服务总是莫名其妙的运行一段时间后JVM直接OutOfMemory错误，内存泄漏的问题不容易查找，本文就一些查找内存泄露基本知识做个总结，未涉及到具体案例的分析。

1JVM内存异常的数据显示

1.1java.lang.OutOfMemoryError:PermGenspace异常的例子

permanentspace持久空间:用于类和方法对象的存储。spring在AOP时使用CBLIB会动态产生很多类，当类太多，超过MaxPermSize的时候，就会抛出此异常。参数问题可以设置jvm启动参数:PermSize,MaxPermSize。程序问题就要进行内存分析了，详见下文。

1.2java.lang.OutOfMemoryError:Javaheapspace异常的例子

edenspace使用率100%，总是被占满，参数问题可以设置jvm启动参数:Xms,Xmx。程序问题就要进行内存分析了，详见下文。

1.3查看jvm内存状态：

异常情况的例子

这个数据显示FullGC频繁发生。

正常情况的例子

参数含义：

S0：Heap上的Survivorspace0段已使用空间的百分比

S1：Heap上的Survivorspace1段已使用空间的百分比

E：Heap上的Edenspace段已使用空间的百分比

O：Heap上的Oldspace段已使用空间的百分比

P：Permspace已使用空间的百分比

YGC：从程序启动到采样时发生YoungGC的次数

YGCT：YoungGC所用的时间(单位秒)

FGC：从程序启动到采样时发生FullGC的次数

FGCT：FullGC所用的时间(单位秒)

GCT：用于垃圾回收的总时间(单位秒)

2Dump出内存

2.1找出要dump的线程pid

在windows下，使用tasklist

在Linux下，使用ps–aux

2.2Dump出内存使用详情

可以通过命令：

也可以通过jconsole的图形界面操作。

在命令行键入：jconsole

Jconsole打开后在造作下选择dumpHeap,输入参数p0,p1;p0表示dump出来的文件路径，后缀为.hprof；p1设为true，表示只分析活着的对象。

jvm调优总结

3使用内存分析工具

目前有很多用来分析Java内存对象的工具，如收费的工具有jprofiler,而像EclipseMAT则是优秀的内存对象分析开源工具.它们对于分析内存溢出问题非常有用。以下是一个安装使用EclipseMAT的简单例子。

3.1装一个Eclipse的内存分析插件MAT

http://download.eclipse.org/technology/mat/latest/update-site/

3.2切换到MemoryAnalysis模式

jvm调优总结

3.3通过File>OpenHeapDump....查看dump出来的文件

jvm调优总结

4JDK自带的JVM查看分析工具jps、jmap、jstat、jconsole

4.1jps

Java进程查看工具，实际上它和Unix/Linux上面的ps命令的功能差不多

4.2jmap

jmap是一个可以输出所有内存中对象的工具.

*-dump:format=b,file=<filename>转存堆内存到本地文件。

*-histo打印堆里每个类的情况，包含内存占用大小、对象数量及完整类名。VM的内部类以"*"开头。

例子：

查看a.log

说明：

classname对应的就是Class文件里的class的标识

B代表byte

C代表char

D代表double

F代表float

I代表int

J代表long

Z代表boolean

前边有[代表数组，[I就相当于int[]

对象用[L+类名表示

4.3jstat

jstat是vm的状态监控工具，监控的内容有类加载、运行时编译及GC。

使用时，需加上查看进程的进程id，和所选参数。以下详细介绍各个参数的意义。

jstat-classpid:显示加载class的数量，及所占空间等信息。

jstat-compilerpid:显示VM实时编译的数量等信息。

jstat-gcpid:可以显示gc的信息，查看gc的次数，及时间。其中最后五项，分别是younggc的次数，younggc的时间，fullgc的次数，fullgc的时间，gc的总时间。

jstat-gccapacity:可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。其他的可以根据这个类推，OC是old内纯的占用量。

jstat-gcnewpid:new对象的信息。

jstat-gcnewcapacitypid:new对象的信息及其占用量。

jstat-gcoldpid:old对象的信息。

jstat-gcoldcapacitypid:old对象的信息及其占用量。

jstat-gcpermcapacitypid:perm对象的信息及其占用量。

jstat-utilpid:统计gc信息统计。

jstat-printcompilationpid:当前VM执行的信息。

除了以上一个参数外，还可以同时加上两个数字，如：jstat-printcompilation30242506是每250毫秒打印一次，一共打印6次，还可以加上-h3每三行显示一下标题。

例子：

一个javaGUI监视工具，可以以图表化的形式显示各种数据。并可通过远程连接监视远程的服务器VM。

================================================================

Oracle®JRockitJDKToolsGuideJDKTools官方文档

http://blog.csdn.net/chenyi8888/article/details/8488727jrockit的dump操作简介

1.输出GC日志

    输出GC日志对于跟踪分析GC的状况来说，无疑是最直接地分析内存回收状况的方法，只是GC日志输出后需要人为地进行分析，以判断GC的状况。

    JVM支持将日志输出到控制台或指定的文件中，方法有如下几种。

    输出到控制台

    在JVM的启动参数中加入-XX:+PrintGC-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintGCApplicationStoppedTime，按照参数的顺序分别输出GC的简要信息，GC的详细信息、GC的时间信息及GC造成的应用暂停的时间。

    输出到指定的文件

    在1中的jvm启动参数中再增加-Xloggc:gc.log可指定将gc的信息输出到gc.log中。

    可用于GC跟踪分析的参数还有-verbose:gc、-XX:+PrintTenuringDistribution等。

2.GCPortal

3.JConsole

JConsole可以图形化查看JVM中内存的变化状况，JConsole是JDK5及以上版本中自带的工具，位于JDK的bin目录下，运行时直接运行JConsole.exe或JConsole.sh（要求支持图形界面）

4.JVisualVM

    JVisualVM是JDK6update7之后推出的一个工具，它类似于JProfiler的工具，基于此工具可查看内存的消耗情况、线程的执行状况及程序中消耗CPU、内存的动作。

    在内存分析上，JVisualVM的最大好处是可通过安装VisualGC插件来分析GC趋势、内存消耗详细状况。

4.JMap

    JMap是JDK中自带的一个用于分析JVM内存状况的工具，位于JDK的bin目录下。使用JMap可查看目前JVM中各个代的内存状况、JVM中对象的内存的占用状况，以及导出整个JVM中的内存信息。

在linux上执行jmap-heap[pid]，就可查看整个JVM中内存的状况

    执行如下命令即可导出整个jvm中的内存信息：

jmap-dump:format=b,file=文件名[pid]

6、JHat是SunJDK6及以上版本中自带的一个用于分析jvm堆dump文件的工具，基于此工具可分析jvmheap中对象的内存占用状况、引用关系等。

    执行如下命令分析jvm堆的dump文件：

  执行后等待console中输出StartedHTTPserveronport7000，看到后就可以通过浏览器访问http://ip:7000了，此页面默认为按package分类显示系统中所有的对象实例。

7.JStat

JStat是SunJDK自带的一个统计分析JVM运行状况的工具，位于JDK的bin目录下，除了可用于分析GC的状况外，还可用于分析编译的状况、class加载的状况等。

    JStat用于GC分析的参数有：-gc、-gccapacity、-gccause、-gcnew、-gcnewcapacity、-gcold、-gcoldcapacity、-gcpermcapacity、-gcutil。常用的为-gcutil。通过-gcutil可按一定频率查看jvm中各代的空间的占用情况、minorGC的次数、消耗的时间、fullGC的次数及消耗的时间的统计，执行jstat-gcutil[pid][interval]

  EclipseMemoryAnalyzer是Eclipse提供的一个用于分析jvm堆dump文件的插件，借助这个插件可查看对象的内存占用状况、引用关系、分析内存泄露等。

    EclipseMemoryAnalyzer（MAT）的网站为：http://www.eclipse.org/mat/，在eclipse中可以直接远程安装此插件。不过由于此插件在分析堆dump文件时比较耗内存，因此在分析前最好先将eclipse的jvm的内存设置大一点，MAT分析dump文件后的对象占用内存及引用关系如图3所示。

    相对而言MAT功能比jhat强大很多，分析的速度也快一些，因此，如果要分析jvm堆dumap文件，首选推荐的是MAT。

    在进行JVM内存状况分析时，通常要关注的主要有GC的趋势、内存的具体消耗状况。

    GC趋势对于可图形界面连到需查看GC状况的机器的情况而言，VisualVM是常用的选择；对于不能采用图形界面方式的，输出GC日志及采用jstat命令直接分析是常用的选择。

    在查找内存是程序中的什么对象占用时，需要分析内存的具体消耗状况，对于有图形界面可用的情况，VisualVM是常用的选择；对于不能采用图形界面方式的，可通过jmapdump生成文件后，再通过MAT进行分析是常用的选择。

======================================================

http://blog.csdn.net/zhoutao198712/article/details/7783070一步步优化JVM四：决定Java堆的大小以及内存占用

http://blog.csdn.net/fenglibing/article/details/6411951jstat介绍

http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/jstat.html官方文档jstat介绍

http://docs.oracle.com/cd/E15289_01/doc.40/e15062/toc.htmJRockitJVMCommand-LineOptions官方文档

http://docs.oracle.com/middleware/1213/wls/index.htmlWeblogic的官方文档

http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/aboutjrockit.htmlAbouttheOracleJRockitJDK官方文档

http://www.oracle.com/technetwork/java/javase/matrix6-windows-140461.htmlQuickTroubleshootingTipsonWindowsforJavaSE6，JDK6中常用监视的命令用法

==================================================

http://www.open-open.com/home/space.php?do=blog&id=8891&uid=71669OOM的常见情况：

第一类内存溢出，也是大家认为最多，第一反应认为是的内存溢出，就是堆栈溢出：

那什么样的情况就是堆栈溢出呢？当你看到下面的关键字的时候它就是堆栈溢出了：

也就是当你看到heap相关的时候就肯定是堆栈溢出了，此时如果代码没有问题的情况下，适当调整-Xmx和-Xms是可以避免的，不过一定是代码没有问题的前提，为什么会溢出呢，要么代码有问题，要么访问量太多并且每个访问的时间太长或者数据太多，导致数据释放不掉，因为垃圾回收器是要找到那些是垃圾才能回收，这里它不会认为这些东西是垃圾，自然不会去回收了；主意这个溢出之前，可能系统会提前先报错关键字为：

这种情况是当系统处于高频的GC状态，而且回收的效果依然不佳的情况，就会开始报这个错误，这种情况一般是产生了很多不可以被释放的对象，有可能是引用使用不当导致，或申请大对象导致，但是javaheapspace的内存溢出有可能提前不会报这个错误，也就是可能内存就直接不够导致，而不是高频GC.

第二类内存溢出，PermGen的溢出，或者PermGen满了的提示，你会看到这样的关键字：

关键信息为:

原因：系统的代码非常多或引用的第三方包非常多、或代码中使用了大量的常量、或通过intern注入常量、或者通过动态代码加载等方法，导致常量池的膨胀，虽然JDK1.5以后可以通过设置对永久带进行回收，但是我们希望的是这个地方是不做GC的，它够用就行，所以一般情况下今年少做类似的操作，所以在面对这种情况常用的手段是：增加-XX:PermSize和-XX:MaxPermSize的大小。

第三类内存溢出：在使用ByteBuffer中的allocateDirect()的时候会用到，很多javaNIO的框架中被封装为其他的方法

溢出关键字：

如果你在直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而不做clear的时候就会出现类似的问题，常规的引用程序IO输出存在一个内核态与用户态的转换过程，也就是对应直接内存与非直接内存，如果常规的应用程序你要将一个文件的内容输出到客户端需要通过OS的直接内存转换拷贝到程序的非直接内存（也就是heap中），然后再输出到直接内存由操作系统发送出去，而直接内存就是由OS和应用程序共同管理的，而非直接内存可以直接由应用程序自己控制的内存，jvm垃圾回收不会回收掉直接内存这部分的内存，所以要注意了哦。

如果经常有类似的操作，可以考虑设置参数：-XX:MaxDirectMemorySize

第四类内存溢出错误：

溢出关键字：

这个参数直接说明一个内容，就是-Xss太小了，我们申请很多局部调用的栈针等内容是存放在用户当前所持有的线程中的，线程在jdk1.4以前默认是256K，1.5以后是1M，如果报这个错，只能说明-Xss设置得太小，当然有些厂商的JVM不是这个参数，本文仅仅针对HotspotVM而已；不过在有必要的情况下可以对系统做一些优化，使得-Xss的值是可用的。

第五类内存溢出错误：

溢出关键字：

上面第四种溢出错误，已经说明了线程的内存空间，其实线程基本只占用heap以外的内存区域，也就是这个错误说明除了heap以外的区域，无法为线程分配一块内存区域了，这个要么是内存本身就不够，要么heap的空间设置得太大了，导致了剩余的内存已经不多了，而由于线程本身要占用内存，所以就不够用了，说明了原因，如何去修改，不用我多说，你懂的。

第六类内存溢出：

溢出关键字

这类错误一般是由于地址空间不够而导致。

六大类常见溢出已经说明JVM中99%的溢出情况，要逃出这些溢出情况非常困难，除非一些很怪异的故障问题会发生，比如由于物理内存的硬件问题，导致了codecache的错误（在由bytecode转换为nativecode的过程中出现，但是概率极低），这种情况内存会被直接crash掉，类似还有swap的频繁交互在部分系统中会导致系统直接被crash掉，OS地址空间不够的话，系统根本无法启动，呵呵；JNI的滥用也会导致一些本地内存无法释放的问题，所以尽量避开JNI；socket连接数据打开过多的socket也会报类似：IOException:Toomanyopenfiles等错误信息。

JNI就不用多说了，尽量少用，除非你的代码太牛B了，我无话可说，呵呵，这种内存如果没有在被调用的语言内部将内存释放掉（如C语言），那么在进程结束前这些内存永远释放不掉，解决办法只有一个就是将进程kill掉。

另外GC本身是需要内存空间的，因为在运算和中间数据转换过程中都需要有内存，所以你要保证GC的时候有足够的内存哦，如果没有的话GC的过程将会非常的缓慢。

=======================================================================