读者看见打印堆栈可能会比较疑惑为什么要打印堆栈，不是调试的时候能看见堆栈信息么，那我先列举如下的两个场景：
场景展示
目标方法如下(可以先不看)：
public void acceptTask(Player player, int modelId, boolean isLogin) {
log.error(TaskHelp.getPlayerInfo(player)+"开始接日常任务："+modelId + " isLogin: "+isLogin);
//省略其他代码
}
下面的场景借上面的那个方法来展开说明
场景一：
- 小明在本地开发游戏时出现一个问题（即玩家在请求一键完成任务的时候，最后还有一个任务没有完成），查阅日志（即目标方法唯一粘贴的语句）发现原因就是
acceptTask方法被不正当的调用了一次，那个没有完成的任务就是因为多接取了一次。 - 小明说好吧，那我看看这个方法被哪些地方调用了，结果一看，妈呀，几十处被调用的地方。小明本意是想着如果只有这么一两处调用，直接看看排查一下就行了的。几十处有点多。
- 小明心想我调试一下看看堆栈就知道了，于是断点就设置在
acceptTask方法的第一行，程序一运行，诶不对啊，断点都进来几十次了，还是没有发现一些异常堆栈信息。
场景二：
- 还是同样的问题出现在了正式的运行的服务器上面，没法调试。
问题解决
哈哈，‘小明’就是我自己咯，只是不好意思当时查找这个问题费了很多时间。
好了言归正传，我以前只注意到在我们程序报错的时候会打印错误堆栈信息。但是我的程序没有报错，而是逻辑错了，于是我就google了一下，我们可以通过如下的方法来打印调用到此处的线程的目前的堆栈信息。
public void acceptTask(Player player, int modelId, boolean isLogin) {
log.error(TaskHelp.getPlayerInfo(player)+"开始接日常任务："+modelId + " isLogin: "+isLogin);
Thread.dumpStack();
}
其实就一行还是JDKThread自带的，Thread.dumpStack();我的那处出问题的逻辑就是这样发现的。打印的信息类似异常堆栈信息，在控制台是红色的比较醒目。
善后处理
进入dumpStack内部：
public static void dumpStack() {
new Exception("Stack trace").printStackTrace();
}
其实这个和我们的异常堆栈信息打印是一样的：
try {
//逻辑代码
} catch (Exception e) {
e.printStackTrace(System.out);
}
只是dumpStack的Exception对象是我们自己new的，而异常堆栈是JVM创建的，所以在问题查找到以后应该及时清理掉这处代码，避免无用对象的创建和回收。
总结
什么时候我们应该打印堆栈？
- 类似场景一，那种即便是可以调试，但是干扰消息太多的情况下。
- 高并发的场景真的不太好调试的时候。
- 类似场景二，无法调试，如果目标代码可以热加载，那就加上
Thread.dumpStack();,然后再加载一次。
PS：其他一些需要堆栈信息的情况？
- 运行中的程序出现了死锁，死循环，这些情况线程几乎是静止的（就是出问题的线程没有栈帧的压入和压出）。这些情况就比较好办直接使用jvm的
jstack工具就行了，这儿我打算写一篇文章，以后写好了，链接过来。
