Hibernate导致的内存溢出问题

在使用Hibernate的过程中发现如下问题:

若在HQL语句中包含IN子句,并且在IN中选项过多则会出现如下异常:

java.lang.StackOverflowError:

at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:42)

at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:41)

at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:41)

at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:41)

at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:41)

at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:42)

.....

例如:

from XX where XX.AA in (1,2,....,10000)

这是由于Hibernate解析HQL时使用递归算法导致的,在in条件中有多少个Item,则visitDepthFirst会递归多少次,最终会导致内存溢出。

解决办法:

1.升级Hibernate版本:Hibernate 3.2.x以上版本上已经解决此问题。

2.将IN子句拆分为多个:

例如:...where XX.AA IN (1,2,...10000)拆分为....where (XX.AA IN (1,2,...,1000)) or (XX.AA IN (1001,1002,...,2000)) or .....or (XX.AA IN (9001,1002,...,10000))

这样可以解决内存溢出问题。

时间: 2024-10-20 01:36:24

Hibernate导致的内存溢出问题的相关文章

drools规则引擎因为内存泄露导致的内存溢出

进入这个问题之前,先了解一下drools: 在很多行业应用中比如银行.保险领域,业务规则往往非常复杂,并且规则处于不断更新变化中,而现有很多系统做法基本上都是将业务规则绑定在程序代码中. 主要存在的问题有以下几个方面: 1) 当业务规则变更时,对应的代码也得跟着更改,每次即使是小的变更都需要经历开发.测试验证上线等过程,变更成本比较大. 2) 长时间系统变得越来越难以维护. 3) 开发团队一般是由一个熟悉业务的BA(业务分析人员)和若干个熟悉技术的开发人员组成,开发人员对业务规则的把握能力远不及

Ubuntu 16.04中XMind 8导致Java内存溢出的问题解决(硬盘卡死,桌面卡死)

XMind使用的是Java进行开发,如果出现内存溢出的问题,那么一定是桌面快捷方式的问题,解决方法是直接修改快捷方式里面的内容,修改如下: [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=XMind Icon=xmind.png Path=/opt/xmind8/XMind_amd64 Exec=/opt/xmind8/XMind_amd64/XMind StartupNotify=false StartupWMC

高并发下Netty4底层bug导致直接内存溢出分析

事故记录: 10点游戏开服,迅速冲破2300+单区同时在线 18点15分,运营反应玩家进不了,准备吃饭的人被抓回来排查故障 发现,由于直接内存被占满,一直在Full GC ,并且回收不掉,所以完全不处理玩家请求,通知运维重启服务器,临时解决. 2.考虑了下是不是把RPC连接数量改成了8条,超时改长了了导致,试着把数量减少,超时改成2个小时,发现直接内存随着时间推移还在增加. 3.把内存数据dump了一份下来,发现是netty底层占用比例大大超出了正常水平. 输出缓冲区ChannelOutboun

JPA出现recursion 死循环导致栈内存溢出问题 Could not write JSON: Infinite recursion (StackOverflowError)

@JsonIgnore 被注解的字段忽略被序列化, 字段不再赋值. @JsonBackReference 只是遇到recursive只会序列化一遍,  序列化过的不会再循环序列化了, 字段还是会赋值. 原文地址:https://www.cnblogs.com/smileblogs/p/12341114.html

Andorid 内存溢出与内存泄露,几种常见导致内存泄露的写法

内存泄露,大部分是因为程序的逻辑不严谨,但是又可以跑通顺,然后导致的,内存溢出不会报错,如果不看日志信息是并不知道有泄露的.但是如果一直泄露,然后最终导致的内存溢出,仍然会使程序挂掉.内存溢出大部分是关于图片的请求,然后又没有及时的释放内存,而导致的内存泄露. 下面是几种常见的导致内存泄露的写法.有些是收集的别的地方的,我也是看到才知道自己写错了,分享一下吧 1.单例造成的内存泄漏 大家都喜欢用Android的单例模式,不过使用的不恰当的话也会造成内存泄漏.因为单例的静态特性使得单例的生命周期和

JVM(三)-内存溢出OutOfMemoryError

一.内存溢出OutOfMemoryError (1)java堆溢出 ①Java堆用于存储对象实例,只要不断地创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常. 代码清单1中代码限制Java堆的大小为20MB,不可扩展(将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展),通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出

有效解决Android加载大图片时内存溢出的问题

首先解析一下基本的知识: 位图模式,bitmap颜色位数是1位 灰度模式,bitmap颜色位数是8位,和256色一样 RGB模式,bitmap颜色位数是24位 在RGB模式下,一个像素对应的是红.绿.蓝三个字节 CMYK模式,bitmap颜色位数是32位  在CMYK模式下,一个像素对应的是青.品.黄.黑四个字节 图像文件的字节数(Byte) = 图像分辨率*颜色深度/8(bit/8) 例如:一幅640*480图像分辨率.RGB色一般为24位真彩色,图像未经压缩的数据容量为:640X480X24

java常见内存溢出情形

虚拟机栈溢出(如果虚拟机在扩展时无法申请到足够的内存空间将抛出OutOfMemoryError) package com.jvm.memory; import java.util.ArrayList; import java.util.List; public class HeapOOM { /** * VM 运行时参数 -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError * @param args */ public static void main

深入理解JVM读书笔记一: Java内存区域与内存溢出异常

Java虚拟机管理的内存包括几个运行时数据内存:方法区.虚拟机栈.本地方法栈.堆.程序计数器,其中方法区和堆是由线程共享的数据区,其他几个是线程隔离的数据区. 2.2 运行时数据区域 2.2.1程序计数器 程序计数器是一块较小的内存,他可以看做是当前线程所执行的行号指示器.字节码解释器工作的时候就是通过改变这个计数器的值来选取下一条需要执行的字节码的指令,分支.循环.跳转.异常处理.线程恢复等基础功能都需要依赖这个计数器来完成.如果线程正在执行的是一个Java方法,这个计数器记录的是正在执行的虚