greys是Btrace的升级版。
与Btrace相比，它直接把最常用的几个操作封装成交互式的命令，免去脚本的编写，使用更加简单。
greys有很多好用的功能，特别是watch命令可以看到方法调用的入参和结果，stack命令还可以看到方法的调用栈，非常的好用。
调试常见的方法是debug和写日志，这个两个方法其实都不是特别方便
平常的调试代码用debug或者远程debug，但是web或者rpc处理都是和超时相关的，一暂停所有的逻辑都乱了。
而且很多时候远程debug的端口都是没开的，还要开下debug端口重启。特别是对于生产环境有端口限制或者环境隔离，是根本远程调试不了的。
对于写日志，但是每次加个日志，重新部署，太慢了。而且很容易日志太多。最后还要把这些日志删除。
举个greys调试栗子：
代码里报一堆的空指针异常，用greys来排查
image.png
报错地方的代码是这样的：
image.png
按道理是不会有null出现的啊，不死心，用greys的watch命令查看下
watch -n 30 -f *JsonUtil readValue '"params[0]="+params[0]+"==="+returnObj'
image.png
可以看到确实是有地方传入的是null，这个的来源是另外一个地方序列化过来的，难道是序列化的结果是null？
赶紧用greys的watch命令查看看序列化的结果
watch -n 30 -f *JsonUtil toJsonByteArray '"params[0]="+params[0]+"==="+returnObj'
image.png
发现完全没有看到null啊。
这个时候可以排除是序列化的原因了，那问题只能是反序列化这块的原因了。
这样排查问题就只看反序列这块的代码了。
image.png
原来读到没数据的时候会返回null，这样就找到问题的原因了。
解决办法：加个null判断就好了
image.png
