今天在做电子归档打包移交的时候出现了下面这个问题
Caused by: java.lang.OutOfMemoryError: Java heap space
at com.linewell.core.db.JDBCTool.doSQLQuery(JDBCTool.java:70)
at com.linewell.core.db.DbObjectManager.doFindListByCondition(DbObjectManager.java:219)
at com.linewell.apas.info.attr.ApasAttrManager.doFindListByCondition(ApasAttrManager.java:84)
at com.linewell.was.archive.ArchiveToZipManager.getattrXml(ArchiveToZipManager.java:925)
at com.linewell.was.archive.ArchiveToZipManager.createXmlFile(ArchiveToZipManager.java:868)
at com.linewell.was.archive.ArchiveToZipManager.doReduceZip(ArchiveToZipManager.java:141)
at com.linewell.was.job.ArchiveToZipJob.execute(ArchiveToZipJob.java:69)
at com.linewell.core.task.taskscheduling.TaskSchedulingManager.run(TaskSchedulingManager.java:83)
at com.linewell.core.task.taskscheduling.TaskSchedulingAction.execute(TaskSchedulingAction.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:450)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
at org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
at org.apache.struts2.interceptor.DeprecationInterceptor.intercept(DeprecationInterceptor.java:41)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
at org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:256)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:167)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:265)
at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
网上搜索了很多方法,设置堆内存大小什么的都试过了,都没有用。后来只能从代码层面来解决问题。通过逐步分析报错最终将问题锁定到了.ArchiveToZipManager.getattrXml,ArchiveToZipManager的getattrXml方法如下
意思就是根据某个punid查询材料信息,通过debug分析得知,当punid=''的时候就会出现上面的报错,后来我通过这个条件查询了一下数据库,结果如下
正常情况下punid是不为空的,后来把这条数据先备份一下,然后删除,再运行时,没有出现上面问题了。代码层次导致java.lang.OutOfMemoryError: Java heap space,
建议大家可以从一下几个方面入手。
- 检查代码中是否有死循环或递归调用。
- 检查是否有大循环重复产生新对象实体。
- 检查对数据库查询中,是否有一次获得全部数据的查询。一般来说,如果一次取十万条记录到内存,就可能引起内存溢出。这个问题比较隐蔽,在上线前,数据库中数据较少,不容易出问题,上线后,数据库中数据多了,一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
- 检查List、MAP等集合对象是否有使用完后,未清除的问题。List、MAP等集合对象会始终存有对对象的引用,使得这些对象不能被GC回收。