背景：
问题：
有个渠道支付服务，负责与所有支付相关服务进行交互，包括 渠道下单支付，渠道成功通知，渠道的对账等
服务4台机，平时跑的都很稳定，通过thrift进行对外提供服务，且平时并未发现访问超时的情况，已经平稳在线上跑了1年多了，没出现过超时问题。
但最近发现，每天到了晚上凌晨2点开始大量服务访问超时，且定位到每次都是抢到对账任务的那台服务出现问题。
解决：
后通过监控和打印GC日志发现，出现问题机器服务的Major GC频率增加，应该是内存问题。
故把对账程序拆出后单独部署后， 再没出现服务访问超时情况。
分析，对账时，因为要捞出当天支付数据到内存进行对账（随着业务发展订单开始猛增）故触发了GC。其实增加分批limit当然也可以解决
这是最近第二次踩到GC的坑了， 第一次是每次访问给每个线程分配的内存过多，并发上来后性能严重降低，导致WEB超时，有必要总结下了
重现下：
死磕重现下，
模拟业务部分，假使每个业务需要500ms返回，代码如下：
/**
* 模拟当系统中使用大对象时,对JVM造成的影响
*
* @author 包子(何锦彬). 2017.01.07
* @QQ 277803242 */@WebServlet("/Test")public class Test extends HttpServlet { private static final long serialVersionUID = 1L; private Logger logger = Logger.getLogger(Test.class.getName()); protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { long startTime = System.currentTimeMillis(); &n
