适用版本EAS820问题描述业务功能无法访问，检查发现实例异常，过一会又自行恢复正常。
原因分析：查看eas\admin\logs\ha.log日志，发现是健康检查机制发现实例异常，自动重启了实例，日志中记录异常情况是Connection_pool_leakage
Ha.log中的日志记录，可判断实例当时可能出现了如下几种情况中的某一种：一、业务功能点代码中存在连接泄露情况，获取了数据库jdbc连接后未主动释放连接，导致连接一直占用状态，此类场景需修改对应代码进行优化。二、数据库jdbc连接池满80个的情况，可能原因如下：1、 业务量巨大，实例负载不足以支撑，此时需要增加实例进行分担压力。2、 线程阻塞或者线程死锁导致，需要找到阻塞或者死锁的源头线程，对应进行优化处理。3、 数据库阻塞或数据库异常，导致线程都在等待数据库响应。持续监控并在数据库jdbc连接池处于较高位时抓取jdbc连接日志进行分析，发现连接池中存在大量相同的总账相关功能的ACTIVE状态的连接。
此时，结合该实例的线程堆栈信息，发现这些活动连接对应的线程也都是活动中，由此可排除是该业务功能存在连接泄露的场景，再进一步分析存活的线程堆栈，发现大量线程都是在等待创建临时表，线程确实存在阻塞现象。
由此可判定是临时表创建失败导致实例出现了线程阻塞现象。而检查sqlserver数据库层面，并未发现有数据库阻塞或死锁现象存在。
查看当时数据库临时表情况，结合临时表机制，从而定位是由于在sqlserver数据库下，默认采用的truncate临时表回收策略存在异常，导致回收失败，这样临时表池里的表越来越多，达到上限（3万）后就无法继续创建临时表了。
解决方法：修改临时表回收策略，在sqlserver数据库下，采用drop策略，废弃truncate策略。具体操作步骤：1、编辑服务器实例下\eas\server\profiles\server*（每个实例）\config\bosconfig.xml文件，将 中的 修改为2、修改完后，重启实例生效。 
