Why HouseMD

分析Java程序问题的手段有很多, 从屌丝System.out.print, 到高富帅YJP, 再到神器BTrace. 用好它们都能切实的解决问题.

那么为什么会需要HouseMD呢? 主要是上述手段在, 用于高负载的服务器端Java程序诊断中都会有些弊端.

日志输出

System.out.print也好, 使用logging的lib也好, 这类日志输出的问题在于:

• 输出日志的点覆盖不全, 一旦变化, 则需要修改代码 -> 编译 -> 部署 -> 重启;
• 输出日志的过多带来的资源消耗在高负载场景下是很可观的, 同时造成分析的成本也高.

Profiler

像YJP这类的Profiler功能强大, 界面华丽, 在单机开发环境中非常好用, 可惜:

• 服务器一般是字符界面, 不方便在服务器上用(要真想, 确实还有办法, 感谢hatter的提示);
• 服务器所在的环境, 可能要通过跳板机, 远程的方式也行不通;
• 要求Java程序启动时配置javaagent;
• 它带来的资源消耗也是不容忽视的;
• 用好它不容易, 学习成本有点高.

BTrace

非常强大, 非常灵活, 只是:

• 引入的增强字节码, 在JVM退出前会始终存在;
• 对一些基于容器的应用支持不够好, 容易出现ClassNotFoundException;
• 很多看似强大的功能, 其实使用场景很少;
• 每当要改变跟踪对象的时候, 需要修改脚本, 很麻烦且易错.

从诊断高负载的Java服务应用看我们需要什么样的诊断工具

因此, 针对上面的这些问题, 可以大致归纳出适用于 高负载服务器端Java程序 诊断工具的特性要求有:

• 命令行接口, 能够方便在服务器环境中运行;
• 支持常用诊断调式手段, 能够在其中快速来回切换;
• 容易定位跟踪目标, 且不易出错;
• 弱侵入, 目标Java程序无需任何修改, 不用重新部署或重启;
• 有效控制给目标进程带来的资源消耗;
• 不遗留任何"代码垃圾"等后遗症.

参考

1. YJP
2. BTrace
3. javaagent
4. 基于AOP的日志调试
5. 动态跟踪Java
6. HouseMD