问题描述
服务器莫名报出ProcessisterminatedduetoStackOverflowException的错误，就这么一句，完全定位不到调用堆栈。百度了也没找到好的方法，有大神有此类经验么，好几万行的代码找递归的地方，真是急死个人
解决方案
解决方案二：
trace啊，完全可以定位到的啊
解决方案三：
可以部署一个debug版（而不是release版），让输出包括行号。在应用中捕获各种exception并记录到日志。关键还是要注意观察，并且在开发环境重现bug步骤。如果不能重现问题，懒得去费心思研究这个，只是浮皮潦草地说“偶尔出现”，通常就只能“等待下一次出现”了，最后很可能使得解决问题的速度比乌龟爬还慢。
解决方案四：
如果这个现象每天出现10次，但是确实找到bug的具体语句的速度“比乌龟爬还慢”，那么可以先看看你们的服务系统有没有“无状态”分层设计。对于99%的核心业务，是可以设计为“无状态”的。这样它就可以随时重启，而不影响业务应用。而仅有1%的需要独立出来的服务器部分才需要“单独”成为一个客户端接入（维持连接）服务，或者甚至只是客户端自动重连而无需服务端保持连接。如果做这样一点点改造，服务器端就可以随时重启，也可以有多台机器同时作为服务。这样如果你用台服务器，即使每天遇到问题而重启100次，客户端也可能“感觉不到”了。
解决方案五：
引用楼主w332981851的回复:
好几万行的代码找递归的地方，真是急死个人
只要大致准确地判断范围，再有足够的日志（比如说一个应用中有20个初日志），这种问题会立刻显现出来。比如说某操作平均1分钟才进行一次，每小时的日志量只有1k，当出现此类问题时，可能就变成了每秒50次操作，每秒增加10k的日志量。此时只要检测一下日志增加情况就知道“出大事儿了”。因此设计开发时选择一个好一点的日志机制也可以有很大帮助的。
解决方案六：
难道你代码里到处都是递归?递归出了问题就那么难查吗