package com.test.learnJava; public class LineNum { public static void main(String[] args) { System.out.println("123"); int ij = 0; String s = "ij="; for (; ; ) { JavaLine javaLine = new JavaLine(); javaLine.P(s + ij); ij++; try { Threa

首先确定要查询的服务进程pid,可用ps -ef|grep 进程名称 jstack -l pid >> stack_info.txt,将此进程的堆栈信息导出到txt文件中 其中"catalina-exec-4"为某一个线程的名称,catalina开头一般为tomcat起的一些线程,线程的pid为nid后的16进制信息,0x2771转为10进制为10097 jmap -histo:live pid > jmap_info.txt 可以导出jvm下存活的堆内存信息 ins

使用如下命令: kill -3 {pid} 可以打印指定线程的堆栈信息到tomcat的catalina.out日志中.在性能测试过程中,可以观察响应时间的曲线,如果突然出现波峰则抓取当前时间点tomcat线程的堆栈信息供后续分析.

命令 jps 查看进程id jstack 1234 查看该进程的线程堆栈信息 对于每个线程,都有如下信息: 线程名,如“main”线程属性(如果是Daemon线程,会有Daemon标识,否则,什么都没有)线程优先级,priojava线程对应的本地线程的优先级os_prijava线程标识tidjava线程对应的本地线程标识nid线程状态(运行中.等待等)线程的栈信息线程锁信息

java-core  P487 P515 chapter11,主要讲java的异常,里面很多内容收获良多,之前一直没注意过的. 一,Throwable类获得StackTraceElement ,可进行堆栈跟踪,用法如下: Throwable t = new Throwable(); StackTraceElement [] frames = t.getStackTrace(); for(StackTraceElement frame :frames) analyze frame Map<Thre

在Java软件的使用过程中,有时会莫名的出现奇怪的问题.而这些问题常常无法使用日志信息定位,这时我们就需要通过查看进程内部线程的堆栈调用关系来分析问题出在哪里. 举个例子,当我们在做某个操作时,莫名的会弹出多个警告框,其中有些信息是正常的,有些则不是.对于这些错误的警告信息,我们该如何定位是哪个位置的代码出现了错误弹出的框呢? 我们就需要在弹框以后,去查看软件的各个线程,去查找究竟是哪个线程导致了该问题.可是有时因为环境.时间等问题,我们根本不能拿着IDE去调试(你总不能拿着笔记本到客户那里说,

介绍 jstack是java虚拟机自带的一种堆栈跟踪工具.jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项"-J-d64",Windows的jstack使用方式只支持以下的这种方式: jstack [-l] pid 主要分为两个功能: a．  针对活着的进程做本地的或远程的线程dump: b．  针对core文件做线程dump. jstack用于生成java虚拟机当前时刻的线程快照.线程快照是当前jav

一.应用场景: 当linux服务器出现异常情况(响应缓慢,负载持续飙升)并且服务器没有安装对应的包而无法使用jstack等命令时,可以使用linux的kill相关命令打印堆栈信息. 命令格式:kill -3 PID 二.执行步骤: 2.1.获取java进程的PID ps -ef|grep java 结果的第二列数字就是进程对应的pid. 2.2.kill -3 PID (1)如果项目通过Tomcat进行发布(普通的web项目),则对应的堆栈信息会打印在catalina.out文件中. (2)如果

最近在生产环境遇到一个问题,正常情况下,ECS CPU始终保持在10%以下,内存也只占用40%左右,但是连续2天出现了CPU占用100%的情况,然后系统卡住.看阿里云的ECS监控,能看到CPU飙到了100%. 再去查日志,发现了有内存溢出的错误GC overhead limit exceeded 这个异常是GC在尝试多次回收后,都回收了不到2%才抛出.一直尝试回收,却一直回收不到2%形成了恶性循环,导致CPU也飙到100%.可以肯定的是一定触发了什么操作才导致这种情况的发生.但是日志当中又看不到

原文地址:http://www.javatang.com 前一段时间上线的系统升级之后,出现了严重的高CPU的问题,于是开始了一系列的优化处理之中,现在将这个过程做成一个系列的文章. 基本概念 在对Java内存泄漏进行分析的时候,需要对jvm运行期间的内存占用.线程执行等情况进行记录的dump文件,常用的主要有thread dump和heap dump. thread dump 主要记录JVM在某一时刻各个线程执行的情况,以栈的形式显示,是一个文本文件.通过对thread dump文件可以分析出

再次,研究了一个下午的jhat好jmap.从一开始惊呆.懵懂于那样大量而无聊乏味的数据,到现在有那么一点点收货.赶紧记录下来.没办法,悟性太低... C:\Users\Administrator>jps Jps C:\Users\Administrator>jps Jps HttpServer C:\Users\Administrator>jmap -dump:file=testJmapa Dumping heap to C:\Users\Administrator\testJmapa

今天工作中,临时Fix一个bug,一看日志“java.lang.ClassCastException: null”相当懵逼,没有详细堆栈信息,这咋整.虽然根据上下文可以推测代码的大致位置,但不敢拍板确认啊.只好google找一下,在Stackoverflow上果然有解决办法 [解决方法]在java启动命令中添加“-XX:-OmitStackTraceInFastThrow”即可输出详细堆栈信息——亲测可用. [问题原因]如果同一个错误的日志频繁发生,为了性能优化,同时不至于同样的堆栈日志频繁刷入

本文博客链接:http://blog.csdn.net/QQ1084283172/article/details/79378374 在进行Android逆向分析的时候,经常需要进行动态调试栈回溯,查看Java函数的调用流程,Android的smali动态调试又不是很方便,因此使用Android的Java Hook的方法,打印Java函数调用堆栈信息辅助静态分析. package com.xposeddemo; import java.util.Map; import android.util.L

很多方式,比如jconsole.jvisualvm,或者jstack -as 这样的形式, 都可以看到实时的java堆栈的变化: eden suvirried0 suvirried1 old perganget major gc minor gc 线程 等等的变化, 但是,问题是,有了这些信息,我们能从中发现什么有价值的东西呢? 总结 虽然电脑中,java程序运行很快,但是我们总是可以获取其一举一动,任何一个细节.其运行中的蛛丝马迹,我们都可以看得清清楚楚,这就现代科技的发达!!

有了mat.同时我们发现Java有提供jvisualvm, jvisualvm是一个不错的工具: heap dump . thread dump. cpu/mem profile 无所不能. 不过观察发现,对同一个java程序,其导出的hrof格式数据跟jmap导出的bin格式数据有所不同,比如String类的count,size等.应该是底层实现不同吧 同时惊人的发现jconsole竟然也可以导出hrof格式的的堆栈信息(参考http://blog.csdn.net/moneyice/arti

背景 在开发Java应用程序的时候,遇到程序抛异常,我们通常会把抛异常时的运行时环境保存下来(写到日志文件或者在控制台中打印出来).这样方便后续定位问题. 需要记录的运行时环境包含两部分内容:抛异常时的参数信息和函数调用堆栈.针对堆栈信息,如果直接调用Exception的getStackTrace方法获取将得到这样一句没用的信息: [Ljava.lang.StackTraceElement;@4361bd48 我们希望能打印完整的调用堆栈,像这样: com.elon.FileNoExistExc

Java 实例 - 获取异常的堆栈信息  Java 实例 以下实例演示了使用异常类的 printStack() 方法来获取堆栈信息: Main.java 文件 public class Main{ public static void main (String args[]){ int array[]={20,20,40}; int num1=15,num2=10; int result=10; try{ result = num1/num2; System.out.println("The r

error显示的log堆栈信息,是从最深层(最内层)的堆栈信息开始由内向外打印的. error显示的log堆栈信息,是从最深层(最内层)的堆栈信息开始由内向外打印的. error显示的log堆栈信息,是从最深层(最内层)的堆栈信息开始由内向外打印的. 即:A调用B,B调用C,C堆栈信息报出error了. 那么就会开始从最内层开始打印这个方法的堆栈信息, 分别是C B A SPRING mvc抛出error,一层层打印堆栈信息,直到最外层的spring dispatcherservlet,再给到容

我们通常会使用工具jstack 去跟踪线程信息,其如何实现使用attach 的方式还是ptrace 的方式,这些可以去参考本人的博客的其他文章. 但这些方式都是外部使用的方式,如何直接使用java代码得到当前进程的线程的信息,方便监控jvm的整个运行状态,就不的不提到了ManagementFactory 通过调用方法 ThreadMXBean tmbean = ManagementFactory.getThreadMXBean(); 通过得到 ThreadMXBean 可以得到非常多的threa

Java多线程——查看线程堆栈信息 摘要:本文主要介绍了查看线程堆栈信息的方法. 使用Thread类的getAllStackTraces()方法 方法定义 可以看到getAllStackTraces()方法的返回值是一个Map对象,key是Thread的实例,value是一个StackTraceElement实例数组: public static Map<Thread, StackTraceElement[]> getAllStackTraces() 使用 可以使用这个静态方法在页面上循环打印

在程序开发中,有时我们不仅需要将异常堆栈信息打印在控制台里或是log里,可能还需要将它存在String中,再送到合适的地方,如错误页面,数据库等. 要取异常堆栈信息,具体的函数就是: /** * Get Exception heap/stack information * @param throwable * @return */ public static String getStackTrace(Throwable throwable) { StringWriter sw = new Str