之前有写 基于AOP的日志调试 讨论一种跟踪Java程序的方法, 但不是很完美.后来发现了 Btrace , 由于它借助动态字节码注入技术 , 实现优雅且功能强大. 只不过, 用起来总是磕磕绊绊的, 时常为了跟踪某个问题, 却花了大把的时间调试Btrace的脚本. 为此, 我尝试将几种跟踪模式固化成脚本模板, 待用的时候去调整一下正则表达式之类的. 跟踪过程往往是假设与验证的螺旋迭代过程, 反复的用BTrace跟踪目标进程, 总有那么几次莫名其妙的不可用, 最后不得不重启目标进程. 若真是线上不能停的服务, 我想这种方式还是不靠谱啊. 为此, 据决定自己的搞个用起来简单, 又能良好支持反复跟踪而不用重启目标进程的工具. AOP AOP是Btrace, jip1等众多监测工具的核心思想, 用一段代码最容易说明: public void say(String words){ Trace.enter(); System.out.println(words); Trace.exit(); } 如上, Trace.enter() 和 Trace.exit() 将say(words)内的代码环抱起来, 对方法进出的进行切面的处理, 便可获取运行时的上下文, 如: 调用栈 当前线程 时间消耗 参数与返回值 当前实例状态 实现的选择 实现切面的方式, 我知道的有以下几种: 代理(装饰器)模式 设计模式中装饰器模式和代理模式, 尽管解决的问题域不同, 代码实现是非常相似,
日志标签 ‘jvm’
动态实时跟踪你的java程序
2011年8月15日深入浅出JVM(四)新一代的垃圾回收算法G1
2010年8月8日垃圾回收的瓶颈
传统分代垃圾回收方式,已经在一定程度上把垃圾回收给应用带来的负担降到了最小,把应用的吞吐量推到了一个极限。但是他无法解决的一个问题,就是Full GC所带来的应用暂停。在一些对实时性要求很高的应用场景下,GC暂停所带来的请求堆积和请求失败是无法接受的。这类应用可能要求请求的返回时间在几百甚至几十毫秒以内,如果分代垃圾回收方式要达到这个指标,只能把最大堆的设置限制在一个相对较小范围内,但是这样有限制了应用本身的处理能力,同样也是不可接收的。
深入浅出JVM(三)分代垃圾回收详述
2010年8月2日深入浅出JVM(一)基本概念
2010年7月19日声明:本专题绝大部分是狠狠的copy自该博客 http://pengjiaheng.javaeye.com/category/86293,在此狠狠的谢谢作者的辛勤劳动!篇幅原因,在该系列的后续文章里,均在此一起感谢原作者了,谢的n次方!
数据类型
Java虚拟机中,数据类型可以分为两类:基本类型和引用类型。基本类型的变量保存原始值,即:他代表的值就是数值本身;而引用类型的变量保存引用值。“引用值”代表了某个对象的引用,而不是对象本身,对象本身存放在这个引用值所表示的地址的位置。