Hibernate在处理数据量比较大的时候内存不释放的解决方案

随着信息化的推进,系统的依赖性也变的越来越强,所以各种数据不断积累,数据开发率并不高,所以数据还不能准确高效的使用,这个时候我们就需要将数据导出到Excel然后通过手工的方式进行处理,但是当讲数据库的数据查询出来的时候,发现JVM的内存持续升高,知道内存溢出,一开始我以为是list太大的原因,我将list固定到1w,然后不断循环去数据库取数据,发现问题依旧存在,没有任何改变,所以说明问题的出处,不在LIST,于是继续寻找,开始进行无用代码隔离,发现问题出现在了hibernate,仔细测试,找到了内存持续增长的地方是Query.list()方法,为了提高效率,尽可能多的占用内存,最终导致内存数据泄露,所以,我使用了最直接的方法,将list.clear()集合清空,发现没有作用,这让我很不可理解,这个返回结果直接返回一个引用,并不是真正的list,此时已经差不多半天时间过去了,问题依然没有解决,想想以前数据量小的时候,很多问题都没有出现,于是调整心态,继续查看API,发现Session情况可以解决问题,于是赶紧试试看,果然,内存在一定范围内稳定下来了,而且数据导出时间和效率明显提高,excel2007在5分钟导出100W数据到1个sheet表很轻松,问题解决了,但是依然感到很不安,原来我对hibernate知识只是了解了一个表面,很多用法还不是很理解,实现原理,实现方式还没有研究过,所以,要走的路还很长,要学的知道还很多,重新拾起自己的激情,开始努力学习吧

时间: 2024-10-10 10:30:23

Hibernate在处理数据量比较大的时候内存不释放的解决方案的相关文章

WCF入门(一)--Request Entity Too large 传输的数据量过大

通过WCF进行数据的查询或者添加的时候,如果数据量过大,一般会报出如下的错误: 1.已超过传入消息(65536)的最大消息大小配额.若要增加配额,请使用相应绑定元素上的MaxReceivedMessageSize 属性. 2.远程服务器返回了意外反应(413)Request Entity too large. 3.远程服务器返回了意外反应(400)Bad Request. 具体的解决方案: 服务端返回数据给客户端报错 在客户端的配置文件中,主要修改maxReceivedMessageSize <

MongoDB数据量较大时如何构建索引--减少业务最少影响

在数据量较大或请求量较大,直接建立索引对性能有显著影响时,可以利用复制集(数据量较大时一般为线上环境,使用复制集为必然选择或者使用分片.)中部分机器宕机不影响复制集工作的特性,继而建立索引. 备注:添加索引的表使用WT引擎,数据量有1.5亿左右. 1. 副本集配置参数 节点1: $ more shard1.conf dbpath=/data/users/mgousr01/mongodb/dbdata/shard1_1 logpath=/data/users/mgousr01/mongodb/lo

关于数据量很大的题目

这段时间写多校,碰到很多数据量很大的题目,有的有规律,有的需要一定的预处理以及一些好玩的算法.那么怎么区分呢?首先看下题目给的限时,如果比较多,那么就需要一定预处理啦:再就是看下rank,如果一道题目突然很多人短时间写出来,一定是规律题,而且是巧妙的规律题.在说一下关于贡献这个东西,有些题目需要枚举,我们在枚举的时候,通常题目表面信息给的枚举是满足不了时间复杂度的,所以我们需要选取合适的枚举对象..这个也很重要.

针对数据量较大的表,需要进行跨库复制,采用navcat 实现sqlite数据库跨数据库的数据表迁移 [转载]

2014年12月13日 14:36 新浪博客 (转自http://www.cnblogs.com/nmj1986/archive/2012/09/17/2688827.html) 需求: 有两个不同的SQLite数据库 A.B,需要将B数据库中的表复制到A数据库中去,数据量较小的时候,可以在数据库可视化工具Navicat中直接将表导成.sql文件,然后将sql文件在另一个数据库运行即可.但是当数据量较大时,这样操作会丢失一部分数据.因此针对这种情况可采用下述方法: 解决办法: (1)使用软件:S

大数据量、高并发数据库的高性能、高可用性解决方案

大数据量.高并发数据库的高性能.高可用性解决方案: 1.拆表:大表拆小表(垂直拆,水平拆:分表,分区partition,分片sharding),可以在应用层实现,也可以在数据库层面实现一部分:提高系统性能. 2.分库:把表放到不同的数据库,这也是分布式数据库的基础:提高系统性能. 3.分布式:不同的数据库放到不同的服务器:提高系统性能. 4.集群:使用数据库复制等技术组建集群,实现读写分离.备份等:提高系统性能.可用性. 5.缓存:对常用的数据进行缓存.提高系统性能. 6.备份:主从库,快照,热

关于android中gridview数据量很大的时候,在加载gridview时会出现卡顿的现象

好的解决办法就是先加载一定数量的数据,然后在最下方提示正在加载! 动态加载就是把放入adapter中的数据分好几次加载.在用户拖动gridview时再加载一定的数据,和sina微博的客户端类似. 给gridview添加OnScrollListener监听事件默认会覆盖下面两个方法: 下面列举个列子: <com.ui.widget.LazyGridView xmlns:android="http://schemas.android.com/apk/res/android" andr

第9条:用生成器表达式来改写数据量较大的列表推导式

核心知识点: (1)当输入的数据量较大时,列表推导可能会因为占用太多内存而出问题. (2)由生成器表达式所返回的迭代器,可以逐次产生输出值,从而避免内存用量问题. (3)把某个生成器表达式所返回的迭代器,放在另一个生成器表达式的for子表达式中,即可将二者结合起来. (4)串在一起的生成器表达式执行速度很快. 列表推导式的缺点是:在推导过程中,对于输入序列中的每个值来说,可能都要创建仅含一项元素的全新列表. 当输入的数据比较少时,不会出任何问题,但如果输入的数据非常多,那么可能会消耗大量内存,并

斯坦福大学公开课机器学习:machine learning system design | data for machine learning(数据量很大时,学习算法表现比较好的原理)

下图为四种不同算法应用在不同大小数据量时的表现,可以看出,随着数据量的增大,算法的表现趋于接近.即不管多么糟糕的算法,数据量非常大的时候,算法表现也可以很好. 数据量很大时,学习算法表现比较好的原理: 使用比较大的训练集(意味着不可能过拟合),此时方差会比较低:此时,如果在逻辑回归或者线性回归模型中加入很多参数以及层数的话,则偏差会很低.综合起来,这会是一个很好的高性能的学习算法. 原文地址:https://www.cnblogs.com/chenwenyan/p/8326027.html

Web传输,前台的参数数据量过大[json格式的字符串],可能达到几M,ajax调用后台方法时

eb传输,前台的参数数据量过大[json格式的字符串],可能达到几M,ajax调用后台方法时,无法传递问题分析:tomcat上默认post提交大小为2M,左右,超过这个大小了,就会传值不成功解决方法:修改post提交大小的限制大小,在server.xml上修改,如下:<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="2000" redirectPort="8