分析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
程序无需任何修改, 不用重新部署或重启; - 有效控制给目标进程带来的资源消耗;
- 不遗留任何"代码垃圾"等后遗症.
HouseMD 便是针对上述特性实现的命令行工具, 欢迎试用
https://github.com/zhongl/HouseMD/wiki/UserGuideCN.