JAVA问题定位技术(B培).ppt

《JAVA问题定位技术(B培).ppt》由会员分享，可在线阅读，更多相关《JAVA问题定位技术(B培).ppt（69页珍藏版）》请在三一办公上搜索。

1、JAVA问题定位技术-常用的手段和工具,Page 2,议题,Page 3,线程堆栈 如何输出线程堆栈,Windows：在运行java的控制台上按ctrl+break组合键Unix：保留启动java的控制台，使用kill-3,堆栈的作用：线程死锁分析辅助CPU过高分析线程资源不足分析性能瓶颈分析关键线程异常退出,启动时进行重定向是一个不错的习惯：run.sh start.log 2&1,Page 4,线程堆栈如何解读线程堆栈？,wait()会释放监视锁sleep()与锁操作无关,继续保持监视锁,当一个线程占有一个锁的时候，会打印-locked 当该线程正在等待别的线程释放该锁，就会打印:wait

2、ing to lock 如果代码中有wait()调用的话，首先是locked,然后又会打印-waiting on,Wait也sleep的重大区别,Page 5,http-0.0.0.0-27443-Processor4 daemon prio=5 tid=0 x599a7520 nid=0 x1858 in Object.wait()5c9ef000.5c9efd88at java.lang.Object.wait(Native Method)-waiting on(a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)at j

3、ava.lang.Object.wait(Object.java:429)at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:655)-locked(a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)at java.lang.Thread.run(Thread.java:534),线程堆栈如何解读线程堆栈？,表示该线程锁柱了该锁,表示正在线程正停在该对象的wait上面。同时wait会自动释放该锁,Page 6,smp

4、p02:Sender-108 daemon prio=5 tid=0 x59a751a0 nid=0 x13fc waiting for monitor entry 6066f000.6066fd88at org.apache.log4j.Category.callAppenders(Category.java:185)-waiting to lock(a org.apache.log4j.spi.RootCategory)at org.apache.log4j.Category.forcedLog(Category.java:372)at org.apache.log4j.Category.

5、log(Category.java:864)at mons.logging.impl.Log4JLogger.debug(Log4JLogger.java:137)at m.base.server.AbstractHandler.send(AbstractHandler.java:407)at com.huawei.tellin.usr.uc.sendmessage.UCSMPPTransaction.send(UCSMPPTransaction.java:102)at com.huawei.tellin.usr.uc.sendmessage.UCServerProxy.synSend(UCS

6、erverProxy.java:134)at m.base.proxy.SendWorker.run(AbstractProxy.java:666)at com.huawei.uniportal.utilities.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)at java.lang.Thread.run(Thread.java:534),waiting to lock 表示该锁已经被别的线程使用，正在等待该锁被释放,线程堆栈如何解读线程堆栈？,Page 7,线程堆栈线程死锁分析,Found one Java-lev

7、el deadlock:=thread1:waiting to lock monitor 0 x009fccb4(object 0 x10032710,a),which is held by thread1thread1:waiting to lock monitor 0 x009fcc94(object 0 x10032718,a),which is held by thread1Java stack information for the threads listed above:=thread1:at DeadLockTest.run(DeadLockTest.java:44)-wait

8、ing to lock(a)-locked(a)at java.lang.Thread.run(Unknown Source)thread1:at DeadLockTest.run(DeadLockTest.java:24)-waiting to lock(a)-locked(a)at java.lang.Thread.run(Unknown Source),虚拟机已经告诉我哪里有死锁了，真不错,0 x10032710 和 0 x10032718 都在等待对方释放，双方都被饿死,Page 8,线程堆栈用户代码导致CPU过高/热点线程分析,首先可以通过kill-3 pid(unix下)或+(wi

9、ndows下)获取一个堆栈信息，几分钟之后再获取一个，通过两个堆栈信息对比，将一直在忙的线程找出来。通过分析对应的代码，确认不正常的线程。第一步：通过kill-3 java_pid 获取当前堆栈信息。第二步：等待一段时间后。再获取一下当前堆栈信息。,Page 9,线程堆栈用户代码导致CPU过高/热点线程分析,第三步：预处理前两个获取的堆栈信息，去掉处于sleeping或waiting的状态的线程。例如如下线程处于wait或者sleep状态，这种线程是不消耗CPU的，因此这些线程可以直接忽略掉，重点关注其它线程：,EventManager-Worker-1 daemon prio=8 tid=0

10、 x00c3ea58 nid=0 x14a in Object.wait()935ff000.935ffc28at java.lang.Object.wait(Native Method)/该线程已挂起，忽略掉-waiting on(a)at java.lang.Object.wait(Object.java:429),第五步：对比预处理后的1，2堆栈信息，找出处于busy状态的线程，该类线程可能是导致cpu高占用率的可疑线程。例如：(下面的是在第一个堆栈信息中找到的处于active 活跃状态的线程)http-80-Processor6 daemon prio=5 tid=0 x013ea77

11、0 nid=0 x143 runnable 92eff000.92f019c0at com.huawei.u_mon.licmgr.LicenseIntf.nativeCheckLicense(Native Method)at com.huawei.u_mon.licmgr.LicenseIntf.checkLicense(LicenseIntf.java:168)at com.huawei.u_sys.meetingone.sysmgr.ejb.LicRelateBean.updateLic(LicRelateBean.java:80),Page 10,线程堆栈用户代码导致CPU过高/热点线

12、程分析,同一个线程在第二个堆栈信息中仍处于活跃状态。http-80-Processor6 daemon prio=5 tid=0 x013ea770 nid=0 x143 runnable 92eff000.92f019c0at com.huawei.u_mon.licmgr.LicenseIntf.nativeCheckLicense(Native Method)at com.huawei.u_mon.licmgr.LicenseIntf.checkLicense(LicenseIntf.java:168)at com.huawei.u_sys.meetingone.sysmgr.ejb.L

13、icRelateBean.updateLic(LicRelateBean.java:80),两次打印堆栈该线程一直在运行，说明该线程已运行了5分钟，请在代码中检查该线程是否属于长时间运行线程？如果属于暂态线程，如此长时间运行说明可能有死循环等导致的CPU过高。,Page 11,线程堆栈线程资源不足分析,aused by:unable to create new native thread;nested exception is:unable to create new native thread at org.jboss.ejb.plugins.AbstractTxInterceptor.in

14、vokeNext(AbstractTxInterceptor.java:214)at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:148)at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111)at org.jboss.ejb

15、.plugins.LogInterceptor.invoke(LogInterceptor.java:191)at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.jav,Caused by:unable to create new native thread at java.lang.Thread.start(Native Method)at.www.http.KeepAliveCache$1.run(KeepAliveCache.java:89)at java.

16、security.AccessController.doPrivileged(Native Method)at.www.http.KeepAliveCache.put(KeepAliveCache.java:75)at.www.http.HttpClient.putInKeepAliveCache(HttpClient.java:382)at.www.http.HttpClient.finished(HttpClient.java:370),线程资源属于数量受限资源，一般一个Java进程中的线程数量不要过多，如果太多虚拟机会拒绝创建。可以通过打印线程堆栈，检查线程的数量，确认问题。如果确实属于

17、线程数量过多，请更改线程模型设计,Page 12,性能瓶颈分析,什么叫高性能？-不同的场合有不同的指标。有的场合高性能意味着用户速度体验，如界面操作。-适合使用OptimizeIt分析还有的场合，高吞吐量意味着高性能，如短信。-适合使用堆栈分析还有的场合是二者的结合，如IP电话-适合使用堆栈分析,Page 13,性能瓶颈分析 Java应用的常见性能陷阱,不良的架构不恰当的线程同步资源的不恰当使用导致的资源竞争不恰当的虚拟机运行参数缓慢的磁盘/网络 IO内存泄漏过分相信Java的自动垃圾回收机制,Page 14,性能瓶颈分析性能设计和调优的原则,80-20原则:20%的代码消耗了80%的资源，2

18、0%的代码执行消耗了80%的时间.当前的性能瓶颈永远只有一处只有解决了当前这一处性能瓶颈，你才知道下一个性能瓶颈在哪里 性能瓶颈是动态的，低负载时不是瓶 颈 的地 方，在高负载时却可能成为瓶颈 性能优化是一个持续的过程 折中的艺术：在性能和灵活性之间寻找平衡点,找出当前性能瓶颈,修改,验证,以稍高于系统的当前能力的压力进行模拟,Page 15,性能瓶颈分析性能分析的手段和方法,JVM手术刀：线程堆栈剖析内存泄漏X光机：内存泄漏分析虚拟机润滑油：JVM参数调优性能调优百宝箱：性能调优工具,Page 16,性能瓶颈分析手段和方法之一线程堆栈剖析,原理：通过分析JVM线程运行情况，定位性能问题方法：

19、kill-3(UNIX)ctrl+break(windows)打印出当前的虚拟机的一个运行剖面，进行分析WorkerThread-8.in Object.wait().-locked(a Queue).WorkerThread-10.in Object.wait().-locked(a Queue).WriterThread-3.in Object.wait().-locked(a Queue).能够发现的性能问题：(1)资源争用(2)锁的粒度过大(3)sleep的滥用适用场合：识别只有在高负载的时候才出现的性能瓶颈。多线程场合不适用的场合：单操作单线程下的代码段耗时分析,如一次界面点击，感觉

20、迟缓。,有一种多线程情况下，需要关注：绝大多数线程处于等待状态，请检查是否有关键路径，没有足够的能力产生线程任务，如：在消息分发系统，消息分发一般是一个线程，而处理是多线程，这时候消息分发是瓶颈的话，观察到的线程堆栈就会出现上面的现象。,Page 17,性能瓶颈分析手段和方法之二 内存泄漏分析,Java 程序也存在内存泄漏内存泄漏表现(1)长时间运行之后系统打印OutOfMemory(2)JVM 莫名其妙地 Core Dump内存泄漏分析通过OptimizeIt,JProfile等可以观察对象的数量和分配的位置JVM 也提供一些工具监控堆的使用情况，尽量使用。内存泄漏避免(1)全局集合 在对象

21、不需要的时侯，从集合中移除(2)缓存 不用的对象及时清理(3)Runnable对象new了就必须使用线程来Run等,Page 18,性能瓶颈分析手段和方法之三 虚拟机调优,原理：观察垃圾回收情况并且进行调整，使JVM的垃圾回收更加平滑和高效率方法：Java 命令行中增加 verbose:gc 运行参数Full GC 792332K-412757K(1040896K),8.9157secsFull GC 799898K-221096K(1040896K),5.3018secs如果每次回收完成后可用的内存持续减少则可能存在内存泄漏。能够发现的性能问题：垃圾回收参数设置不合理导致的严重的性能问题内存

22、泄漏可以调节的JVM 垃圾回收参数IBM JDK：主要参数：-Xconcurrentbackground Xconcurrentlevel,以及堆大小。SUN，HP JDK 主要是-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFractionJVM调优是个系统工程，和运行环境主要是内存配置密切相关，需要酌情配置处理适用场合：高负载但实时性要求不高的系统，如 Web 类应用，如移动彩铃应用，以及大容量且实时性要求非常高的系统，比如呼叫类应用。,Page 19,性能瓶颈分析手段和方法之四 性能调优工具,Optimi

23、zeIt或JProfile 提供全面的内存泄漏分析，函数调用CPU时间和内存占用分析适用场合：（1）单操作单线程下的代码段耗时分析,如一次界面点击，感觉迟缓。不适用的场合：（1）运行期间，同一段代码被不同线程执行时，由于线程是变化的，无法找出对应的线程。（2）大容量应用下出现的瓶颈,因为启动这个工具性能会有几十倍甚至上百倍的的性能下降，难以支撑大容量情况下的测试分析。只有在大容量下出现的锁竞争也许不会出现，频繁的磁盘IO、数据库访问等导致的瓶颈也不会出现。现象不充分暴露，自然也就谈不上分析。,Page 20,性能瓶颈问题产生的源头分析,常见架构和设计问题：同步异步使用不当不合理的负荷分担缺乏必

24、要的缓冲设计并发设计不当资源抢占,连接池和线程池等应用不当等效率低下的通信方式数据库连接缓存使用不当 常见编码问题String+，getByte()的不恰当使用：很多时侯可以使用StringBuf过大的同步范围语句设计不当,Page 21,JAVA 远程调试,虚拟机远程调试开关：-Xdebug-Xrunjdwp:transport=dt_socket,server=y,address=%DEBUG_PORT%,suspend=n,打开调试开关会对JVM的运行速度有影响，仅在需要的时候才这样做,不仅可以调试本机上运行的服务器，还可以调试远程机器,suspend设为n时JVM会在打开调试端口后正常

25、启动，若设为y则JVM启动后会等候调试器连接后才继续启动,Page 22,JAVA 远程调试,在Eclipse中打开调试配置对话框，双击左边树中Remote Java Application增加一项远程调试配置,Project：需要调试的代码所在工程Host：服务器所在机器，可以是打开了调试端口的远程计算机Port：前述打开的调试端口，server的userconfig.bat中的缺省值是3999,Page 23,GC参数/输出解读,下列JVM参数可用于获取gc日志-verbose:gc 或-Xloggc:filename 一些参考资料,Page 24,JAVA 内存泄漏检测,2.1 java

26、的垃圾回收机制java虚拟机的垃圾回收算法要做两件事情。首先，它必须检测出垃圾对象。其次，它必须回收垃圾对象所使用的堆空间并还给程序。垃圾检测通常通过建立一个根对象的集合并且检查从这些根对象开始的可触及性来实现。如果正在执行的程序可以访问到的根对象和某个对象之间存在引用路径，这个对象就是可触及的。对于程序来说，根对象总是可以访问的。从这些跟对象开始，任何可以被触及的对象都被认为是“活动”对象。无法被触及的对象被认为是垃圾，因为它们不再影响程序的未来执行。2.2 内存泄漏的产生如果系统中存在越来越多的不再影响程序未来执行的对象，且这些对象和根对象之间存在引用路径，内存泄漏产生了。2.3 内存泄漏

27、的消除根据 内存泄漏的产生 所述。发生内存泄漏要满足如下两个条件：1.系统中存在越来越多的不再影响程序未来执行的对象。2.这些对象和根对象之间存在引用路径。从这两个条件中能很容易找出消除内存泄漏的方法：截断系统中存在的不影响程序未来执行的对象与根对象之间的引用路径。这样，这些对象就成了“垃圾”对象，jvm就能正常回收它们。,Page 25,JAVA 内存泄漏检测,常见的内存泄露（1）全局HashMap等容器，在对象不需要后没有及时从容器中remove掉（2）Thread只new了，但没有start,Page 26,Java内存泄漏的初步确定,下面是使用GC输出分析内存泄漏的原理:GC 65.2

28、33:DefNew:12949K-1434K(13824K),0.0122730 secs 87703K-76189K(134892K),0.0123500 secs(87703K-76189K(134892K),87703K表示系统使用了多少内存(我们称之为当前使用内存),76189K表示进行这次垃圾回收之后使用的内存数量(我们称之为垃圾回收后内存),134892K上两个数据相减)可以按照如下思路分析GC输出,能够初步比较准确地判断系统是否存在内存泄漏:(1)首先要确保系统已经稳定运行(如初使化等已经完成等)(这个条件很重要)(2)然后取一个时间段的GC 输出作为分析数据，只分析FULL G

29、C的行，以垃圾回收后的值为分析对象(3)然后根据GC分析内存的使用情况:A.如果当前使用内存持续增长,而垃圾回收后内存也持续增长,有一直增长到Xmx设置的内存的趋势,那么这个时侯基本上就可以断定有内存泄漏问题了.B.如果当前使用内存增长到一个值之后,又能回落,达到一个动态平衡,那么就没有内存泄漏的情况.,Full GC 912526K-614350K(912576K),2.5546922 secsFull GC 912526K-623890K(912576K),2.5777505 secsFull GC 912575K-625359K(912576K),2.5620272 secsFull G

30、C 912575K-648552K(912576K),2.5632979 secsFull GC 912532K-688576K(912576K),2.5211377 secsFull GC 912532K-714354K(912576K),2.6212585 secsFull GC 912538K-784362K(912576K),2.5190768 secs,（1）只有FULL GC的行才有分析价值（2）只需要检查完全垃圾后剩余的内存值是否一直再增大。,Page 27,JAVA 内存泄漏精确定位,借助一些工具，如：Optimizeit JProfiler、JRockit等，甚至可以使用Ja

31、va虚拟机自带的工具HProf进行问题的定位；使用HProf的方法如下：java-Xrunhprof 其它参数 要运行的系统main函所在的类具体的参数列表如下：Hprof usage:-Xrunhprof:help|:=,.Option Name and Value Description Default-heap=dump|sites|all heap profiling allcpu=samples|times|old CPU usage offmonitor=y|n monitor contention nformat=a|b ascii or binary output afile=

32、write data to file java.hprof(.txt for ascii)net=:send data over a socket write to filedepth=stack trace depth 4cutoff=output cutoff point 0.0001lineno=y|n line number in traces?ythread=y|n thread in traces?ndoe=y|n dump on exit?ygc_okay=y|n GC okay during sampling yExample:java-Xrunhprof:cpu=sample

33、s,file=log.txt,depth=3 FooClass使用HProf定位内存泄漏问题时，可以通过通过增加参数“heap=sites”来输出堆栈信息到文件中，然后通过分析堆栈信息h和线程信息来判断内存泄漏的位置；,Page 28,JAVA 内存泄漏精确定位 OptimizeIt举例,在系统运行平稳后，做一次垃圾回收，并进行标记；反复进行可能出现内存泄漏的操作，然后再进行一次垃圾回收，并按照“Diff”列进行排序（点击该列即可，该列表示相对于进行标记时的对象的增加数）；观察并记录那些对象是增加的；重复进行上面的操作，找出一直是增加的对象；这些对象将可能是导致内存泄漏的原因。双击打开一直增加

34、的对象，将显示这些对象是由那些对象创建的,Page 29,JAVA 内存泄漏检测-OptimizeIt,使用OptimizeIt定位内存泄露确切位置的步骤：（1）系统稳定运行一段时间，即按照从业务逻辑来讲，不应该再有大的内存需求波动。这个非常重要。（2）点击OptimizeIt上的垃圾回收按钮，然后马上再点mark按钮。将当前实际对象的数量作为基准点。（3）过一段时间（如一个小时或者更多）（4）点击OptimizeIt上的垃圾回收按钮，检查是否有大量的对象增加，如果有增加，主要是哪些对象确定可疑范围，通过结合阅读代码进行分析。,Page 30,Unix下调试利器-Proc工具介绍,/proc文

35、件系统不是普通意义上的文件系统，它是一个到运行中进程地址空间的访问接口。通过/proc，可以用标准Unix系统调用(比如open()、read()、write()、ioctl()等等)访问进程地址空间。大多数Unix(/Linux)操作系统在带一系列的工具集，借助这些工具，可以对进行进行剖析，从而协助定位相关问题。,Windows下可以使用Taskinfo工具分析类似的内容Linux下直接到/Proc下面，大部分数据可读。可结合lsof进行分析,http:/,Page 31,Proc工具列表,pcred pfiles pflags pldd pmap prun psig,pstack psto

36、p ptime ptree pwait pwdx plimit,Page 32,Proc工具介绍pstack,pstack 打印当前进程的每个线程的堆栈信息,9e7932c8 scan_info(1516900,15168b4,1516930,b68,800,b1c)+f8 9e793628 parse(1516900,15168b4,1516924,1516930,9e793544,332a8)+e4 9e78cc90 init(1516948,549,1516900,15168b4,1516924,1516930)+188 9e78cf54 LicFileParseInit(1516948

37、,549,15168b4,1516900,1516924,1516930)+4c 9e79d484 AdaptiveLMStandAloneInitEx(15168b4,1516930,9e7c8ebc,549,9e7a9df3,9e7a9dfe)+480 9e78b04c AdaptiveLMStandAloneInit(1516718,2c6f,9e7c8ebc,549,9e7a9df3,9e7a9dfe)+2c 9e78a3e0 _1cLLicenseInit6Fpkc1_i_(64df28,64df28,0,7efefeff,81010100,ff00)+278 9e78a7c0 Ja

38、va_com_huawei_u_1sys_common_licmgr_LicenseIntf_nativeCheckLicense(ff33a4,932ff308,932ff384,932ff380,70,0)+80 f980b96c?(932ff384,b8,0,bbd7f4d0,0,0),用处：协助定位JNI/本地程序CPU使用过高，线程死锁,通过周期打印堆栈，比较前后堆栈，找出一直处于忙的线程，从而定位出可疑代码范围,打印的堆栈包含锁对象，通过检查多个线程的锁对象，从而定位出死锁位置,代码段的绝对地址,偏移量，即在该位置处调用了其它函数,函数的参数,Page 33,Proc工具介绍pst

39、ack,SolarisAIX pstack=procstack pmap=procmapLinux pstack=lsstack pmap=pmap pfiles=lsofHP Not found,Page 34,Proc工具介绍pstack,-lwp#14/thread#25-ff369764 _sigprocmask(ff36bf60,0,0,e6181d70,ff37e000,0)+8 ff35e110 _sigon(e6181d70,ff385930,6,e6180114,e6181d70,6)+d0 ff361150 _thrp_kill(0,19,6,ff37e000,19,ff2

40、c0450)+f8 ff24b900 raise(6,0,0,ffffffff,ff2c03bc,4)+40 ff2358ec abort(ff2bc000,e6180268,0,fffffff8,4,e6180289)+100 fe3c68fc _1cCosFabort6Fl_v_(1,fe4c8000,1,e61802e8,0,e9f90420)+b8 fe3c59f0 _1cCosbBhandle_unexpected_exception6FpnGThread_ipCpv_v_(ff2c02ac,fe53895c,fe4dc164,fe470ab4,fe4c8000,e6180308)+

41、254 fe20a8b4 JVM_handle_solaris_signal(0,25d5b8,e6180d90,fe4c8000,b,e6181048)+8ec ff36b824 _sighndlr(b,e6181048,e6180d90,fe20a8cc,e6181e14,e6181e04)+c ff3684d8 sigacthandler(b,e6181d70,0,0,0,ff37e000)+708-called from signal handler with signal 11(SIGSEGV)-e9f90420 Java_HelloWorld_displayHelloWorld(2

42、5d644,e6181224,e61819b8,0,2,0)+30 00090ae4?(e6181224,e61819b8,25d5b8,fe4c8000,0,109a0)0008dc4c?(e61812c4,ffffffff,ffffffff,97400,4,e61811b8)0008dc4c?(e618135c,e61819b8,fe4c8000,99600,c,e6181250)0008dc4c?(e61813ec,f76a2f90,e618147c,99600,c,e61812f8)0008ddb4?(e618147c,f68578b8,0,99974,c,e6181388)0008d

43、dd8?(e618154c,e61815c8,e61815cc,99974,4,e6181410)-pmap output snippet:.E9500000 1184K readE9680000 1392K readE9800000 4608K readE9F60000 136K read/write/execE9F90000 8K read/exec/home/usera/wls70/solaris/projectWork/lib/libhello.soE9FA0000 8K read/write/exec/home/usera/wls70/solaris/projectWork/lib/

44、libhello.soE9FB4000 8K read/write/exec.Notice from the pstack output that the address where this happened is at e9f90420.The pmap output snippet shows that e9f90420 falls between E9F90000 and E9FA0000,so the error is happening somewhere within the libhello.so shared object.,Page 35,Proc工具介绍Pfiles,列出

45、该进程打开的文件句柄和socket连接的IO对象 用法：pfiles 用处：查找文件句柄泄漏,465:/usr/j2se/jre/bin/java-DMODULE_TYPE=server-Xms900M-Xmx900M-XX:NewS Current rlimit:65536 file descriptors 0:S_IFCHR mode:0666 dev:313,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE/devices/pseudo/mm0:null 14:S_IFSOCK mode:0666 dev:319,0 ino

46、:34066 uid:0 gid:0 size:0 O_RDWR SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152)sockname:AF_INET 0.0.0.0 port:49416 15:S_IFSOCK mode:0666 dev:319,0 ino:34064 uid:0 gid:0 size:0 O_RDWR SOCK_STREAM SO_SNDBUF(49152),SO_RCVBUF(49152)sockname:AF_INET 0.0.0.0 port:49415 46:S_IFREG mode:0644 dev

47、:118,8 ino:406695 uid:0 gid:0 size:159744 O_RDWR|O_CREAT|O_LARGEFILE/usr/local/uniportal/conf/server/isapdb/seg0/c60.dat 47:S_IFREG mode:0644 dev:118,8 ino:406729 uid:0 gid:0 size:8192 O_RDWR|O_CREAT|O_LARGEFILE/usr/local/uniportal/conf/server/isapdb/seg0/c81.dat 48:S_IFREG mode:0644 dev:118,8 ino:4

48、06733 uid:0 gid:0 size:8192 O_RDWR|O_CREAT|O_LARGEFILE/usr/local/uniportal/conf/server/isapdb/seg0/cc0.dat 49:S_IFREG mode:0644 dev:118,8 ino:406734 uid:0 gid:0 size:8192 O_RDWR|O_CREAT|O_LARGEFILE/usr/local/uniportal/conf/server/isapdb/seg0/cd1.dat,打开的文件,该进程允许打开的最多文件句柄数,建立的socket,Page 36,Proc工具介绍Pf

49、iles,有的时候打印不出具体的文件名：1018:S_IFREG mode:0644 dev:291,0 ino:335047 uid:3221 gid:102 size:2425 O_RDONLY|O_LARGEFILE结合如下命令可以找到打开了哪个文件find.type f exec ls i;print|grep 335047,打开的文件的节点号，如果文件已经被删除，给文件句柄尚未关闭，那么pfiles就无法打印出文件名。,Page 37,Proc工具介绍Pflags,报告指定进程的状态 用法：pflags,465:/usr/j2se/jre/bin/java-DMODULE_TYPE=

50、server-Xms900M-Xmx900M-XX:NewS data model=_ILP32 flags=ORPHAN|MSACCT|MSFORK/1:flags=ASLEEP lwp_cond_wait(0 x383b0,0 x38398,0 x0,0 x0)sigmask=0 x00000004,0 x00000000/2:flags=DETACH|ASLEEP lwp_cond_wait(0 x3d290,0 x3d278,0 x0,0 x0)sigmask=0 x00000004,0 x00000000/3:flags=DETACH|ASLEEP lwp_cond_wait(0 x