问题描述
解决方案
结果是内存益处了
那就是你的程序太耗费资源了。
那个获取page的方法:
1--Page对象村的东西太多了,很多何你写入单元格的数据没关系,
既然这块逻辑是大数据量的,为什么不拆分针对这块逻辑的结构呢?
使用Page造成了很大的内存浪费
在循环外部定义这个结构
List list = null
2--将方法的参数精简下
因为你一页的数据量10000时固定的,所以只要知道这个当前的count就够了
为什么不把方法签名写成下面的呢?
arrearA..Service.getArrearInfoByRow(row,"list,arreAmount",SqlO....)
只要四个参数就够了。
至于其他的参数对于这个xxxService来说,在生成这个Service的时候这个10000是知道的。
map,你第一行程序就有用map作为计算,应该在里面计算的同时保存住map的信息。
方法参数越多,方法调用的成本越高,尤其是那些存有大量数据的对象作为方法参数时不可取的。
至于为什么要改成List呢?
首先:因为你那个Page对象里买的东西太多,很多何这块逻辑每关系,所以不要为了易于使用
就全部封装在一起,这样的对象占用资源厉害啊
其次每次调用一个方法都返回一个Page对象也不合适,返回肯定是new了,对象的空间没有复用
与其你返回一个Page,还不如在参数中定义一个page,这样这个方法不new了,每次都利用参数中的page对象的值。
你只要在循环开始给page来一个初始化就可以了
但是page仍然占用资源,使用这个List作为参数
提示:将大数据对象放到函数体内,函数执行完了会自动释放空间的。函数的返回采用轻便的数据结构存储
还有就是 list可以进行clear()操作。不用每次都new一个list
最后就是使用迭代器来进行循环
总结:
优化的目的就是:
1--避免大数据量的对象传入函数内部
2--不要动不动就返回一个对象,尤其是在多次循环中,这就是多次的new
不如将返回的对象传入参数中,使用完了之后还可以继续复用这个对象的内存
3--结合2,可以给对象定义一个clear操作,执行完成之后给对象的存储减负
这样继续使用的时候效率更高。
希望对你有帮助
解决方案二:
执行异步请求
解决方案三:
500的异常信息是什么呢?
解决方案四:
jvm 调优试试,应该是堆栈内存分配不够。
解决方案五:
http://www.codeproject.com/Articles/492789/Starting-and-Monitoring-a-Long-Running-Task-Using