JAVA内存溢出解决方案
解决溢出问题的方法
解决溢出问题的方法
解决溢出问题的方法主要有以下几种：
1. 代码审查和优化：通过仔细审查代码，找出可能导致溢出的源头，如大量数据的处理、循环引用等。
优化这些代码段，减少内存使用。
2. 调整内存参数：调整JVM的启动参数，如-Xms和-Xmx参数，可以动态调整内存分配。
这可以帮助避免内存溢出。
3. 使用内存分析工具：使用内存分析工具（如MAT）来分析内存使用情况，找出并解决内存泄漏问题。
4. 避免大对象分配：尽量避免一次性分配大量内存，可以将大任务拆分成小任务，逐个处理。
5. 优化数据库查询：数据库查询可能导致大量数据加载到内存中，可以通过优化查询语句，减少数据加载量。
6. 升级硬件：在某些情况下，增加物理内存或升级其他硬件（如硬盘）可能有助于解决溢出问题。
7. 使用缓存技术：对于频繁使用的数据，可以使用缓存技术来减少对数据库的访问，从而减少内存使用。
8. 日志分析：仔细分析应用程序日志，查找可能导致溢出的异常或错误。
9. 垃圾回收优化：根据应用程序的特点，选择合适的垃圾回收策略，以减少内存碎片和垃圾回收开销。
10. 避免第三方软件BUG：确保使用的第三方软件没有已知的内存泄漏问题或BUG，并及时更新软件。
这些方法可以根据实际情况进行选择和应用，一般需要通过不断测试和调优来找到最适合的解决方案。
什么是内存溢出outofmemory？怎么解决
什么是内存溢出outofmemory？怎么解决本⽂主要内容来源于⽹络，博主⾃⼰整理⽽成，仅做知识分享，如有侵权请联系，会及时删除。
1.什么是内存溢出？内存溢出是指应⽤系统中存在⽆法回收的内存或使⽤的内存过多，最终使得程序运⾏要⽤到的内存⼤于虚拟机能提供的最⼤内存。
为了解决Java中内存溢出问题，我们⾸先必须了解Java是如何管理内存的。
Java的内存管理就是对象的分配和释放问题。
在Java中，内存的分配是由程序完成的，⽽内存的释放是由垃圾收集器(GarbageCollection，GC)完成的，程序员不需要通过调⽤GC函数来释放内存，因为不同的JVM实现者可能使⽤不同的算法管理GC，有的是内存使⽤到达⼀定程度时，GC 才开始⼯作，也有定时执⾏的，有的是中断式执⾏GC。
但GC只能回收⽆⽤并且不再被其它对象引⽤的那些对象所占⽤的空间。
Java的内存垃圾回收机制是从程序的主要运⾏对象开始检查引⽤链，当遍历⼀遍后发现没有被引⽤的孤⽴对象就作为垃圾回收。
2.为什么会出现内存溢出？常见有以下情况：（1）内存中加载的数据量过于庞⼤，如⼀次从数据库取出过多数据；（2）集合类中有对对象的引⽤，使⽤完后未清空，使得JVM不能回收；（3）代码中存在死循环或循环产⽣过多重复的对象实体；（4）使⽤的第三⽅软件中的BUG；（5）启动参数内存值设定的过⼩3.内存溢出解决⽅法内存溢出虽然很棘⼿，但也有相应的解决办法，可以按照从易到难，⼀步步的解决。
第⼀步，就是修改JVM启动参数，直接增加内存。
这⼀点看上去似乎很简单，但很容易被忽略。
JVM默认可以使⽤的内存为64M，Tomcat默认可以使⽤的内存为128MB，对于稍复杂⼀点的系统就会不够⽤。
在某项⽬中，就因为启动参数使⽤的默认值，经常报“OutOfMemory”错误。
因此，-Xms，-Xmx参数⼀定不要忘记加。
第⼆步，检查错误⽇志，查看“OutOfMemory”错误前是否有其它异常或错误。
解决Java导入excel大量数据出现内存溢出的问题
解决Java导⼊excel⼤量数据出现内存溢出的问题问题：系统要求导⼊40万条excel数据，采⽤poi⽅式，服务器出现内存溢出情况。
解决⽅法：由于HSSFWorkbook workbook = new HSSFWorkbook(path)⼀次性将excel load到内存中导致内存不够。
故采⽤读取csv格式。
由于csv的数据以x1,x2,x3形成，类似读取txt⽂档。
private BufferedReader bReader;/*** 执⾏⽂件⼊⼝*/public void execute() {try {if(!path.endsWith(".csv")){("-----该⽂件不是以CSV⽂件，请上传正确的⽂件格式------");return ;}Long startTime = System.currentTimeMillis();("------开始执⾏定时任务，时间=" + startTime);readCSV(path);Long endTime = System.currentTimeMillis();("------结束定时任务，时间=" + endTime + "---耗时="+ (endTime - startTime));} catch (Exception e) {e.printStackTrace();}}/*** 读取csv并处理数据* @param path* @throws Exception*/private void readCSV(String path) throws Exception {File file = new File(path);try {bReader = new BufferedReader(new InputStreamReader(new FileInputStream(file), "gbk"));String line = "";//忽略第⼀⾏标题for (int i = 0; i < 1; i++) {line = bReader.readLine();}while((line = bReader.readLine()) != null){if (line.trim() != "") {//分割开来的即是对应的每个单元格，注意空的情况String[] result = line.split(",");}}}} finally {if (bReader != null) {bReader.close();}}}以上这篇解决Java导⼊excel⼤量数据出现内存溢出的问题就是⼩编分享给⼤家的全部内容了，希望能给⼤家⼀个参考，也希望⼤家多多⽀持。
java中遇到的问题和解决方案
java中遇到的问题和解决方案
目录
1. Java中遇到的问题
1.1 内存溢出问题
1.2 死锁问题
2. 解决方案
2.1 内存溢出问题的解决方案
2.2 死锁问题的解决方案
Java中遇到的问题
在Java编程过程中，经常会遇到各种各样的问题，其中两个比较常见的问题是内存溢出和死锁问题。
内存溢出问题是指程序在运行过程中申请的内存超过了系统能够分配给它的内存大小，导致程序崩溃。
这种问题通常发生在程序中频繁创建大量对象或者持续运行时间过长的情况下。
死锁问题则是指多个线程互相持有对方所需要的资源，导致彼此无法继续执行，进而导致程序无法正常运行。
死锁问题通常发生在多线程编程中，处理不当时很容易出现。
解决方案
针对内存溢出问题，可以通过一些方法来解决，比如增加堆内存大小、优化程序代码以减少内存占用、及时释放不再使用的对象等。
另外，可以使用一些工具来监控程序内存使用情况，及时发现并解决潜在的内存溢出问题。
对于死锁问题，可以通过合理地设计程序逻辑、避免使用过多的同步代码块、避免嵌套锁等方法来预防死锁的发生。
此外，可以使用一些工具来帮助检测程序中潜在的死锁问题，并及时处理。
综上所述，如果在Java编程过程中遇到内存溢出或死锁问题，可以通过上述方法来解决，确保程序的稳定运行。
完美解决java读取大文件内存溢出的问题
完美解决java读取⼤⽂件内存溢出的问题1. 传统⽅式：在内存中读取⽂件内容读取⽂件⾏的标准⽅式是在内存中读取，Guava 和Apache Commons IO都提供了如下所⽰快速读取⽂件⾏的⽅法：Files.readLines(new File(path), Charsets.UTF_8);FileUtils.readLines(new File(path));实际上是使⽤BufferedReader或者其⼦类LineNumberReader来读取的。
传统⽅式的问题：是⽂件的所有⾏都被存放在内存中，当⽂件⾜够⼤时很快就会导致程序抛出OutOfMemoryError 异常。
问题思考：我们通常不需要把⽂件的所有⾏⼀次性地放⼊内存中，相反，我们只需要遍历⽂件的每⼀⾏，然后做相应的处理，处理完之后把它扔掉。
所以我们可以通过⾏迭代⽅式来读取，⽽不是把所有⾏都放在内存中。
2. ⼤⽂件读取处理⽅式不重复读取与不耗尽内存的情况下处理⼤⽂件：（1）⽂件流⽅式：使⽤java.util.Scanner类扫描⽂件的内容，⼀⾏⼀⾏连续地读取FileInputStream inputStream = null;Scanner sc = null;try {inputStream = new FileInputStream(path);sc = new Scanner(inputStream, UTF-8);while (sc.hasNextLine()) {String line = sc.nextLine();// System.out.println(line);}}catch(IOException e){logger.error(e);}finally {if (inputStream != null) {inputStream.close();}if (sc != null) {sc.close();}}该⽅案将会遍历⽂件中的所有⾏，允许对每⼀⾏进⾏处理，⽽不保持对它的引⽤。
内存溢出的三种情况及系统配置解决方案
内存溢出的三种情况及系统配置解决方案内存溢出是指程序在运行过程中申请的内存超过了系统或者进程所能提供的上限。
导致内存溢出的原因可能是程序中存在内存泄漏、内存分配过多或者递归调用过深等。
下面将介绍三种常见的内存溢出情况及其系统配置解决方案。
1.程序内存泄漏导致内存溢出：内存泄漏指程序在运行过程中动态分配内存空间后，没有对其进行释放，导致一部分内存无法再次使用。
长时间运行的程序中，如果内存泄漏较为严重，系统可用内存会不断减少，直到最终耗尽所有内存资源。
解决方案：使用内存泄漏检测工具来检测和修复程序中的内存泄漏问题。
同时，可以考虑使用自动内存管理的编程语言，如Java和Python，在程序运行过程中自动回收未使用的内存。
2.内存分配过多导致内存溢出：解决方案：优化程序的内存使用，尽可能减小内存分配的数量和大小。
可以通过使用更高效的内存管理算法来减少内存碎片，或者使用内存池技术来提前分配一定量的内存供程序使用。
3.递归调用过深导致内存溢出：递归函数在每次调用时会将一定量的数据压入栈中，如果递归调用层数过深，栈的空间可能会超过系统的限制，从而导致内存溢出。
这种情况通常发生在没有设置递归终止条件或者递归层数过多的情况下。
解决方案：优化递归算法，设置合适的递归终止条件，避免递归调用过深。
如果无法避免使用递归算法，可以考虑使用尾递归或者迭代算法来替代递归调用，减少栈的压力。
在系统配置方面，可以采取以下措施来预防和解决内存溢出问题：1.增加系统内存容量：如果内存溢出是由于系统可用内存不足引起的，可以考虑增加系统的内存容量。
这可以通过增加物理内存条或者使用虚拟内存技术来实现。
虚拟内存技术会将部分磁盘空间用作缓存，并将一部分数据暂时存储在磁盘上，以释放内存空间。
2. 调整JVM参数：对于使用Java虚拟机（JVM）的应用程序，可以通过调整JVM的参数来控制内存的分配和管理。
例如，可以通过设置-Xmx参数来限制JVM使用的最大堆内存大小，或者通过设置-XX:MaxPermSize参数来限制JVM使用的最大持久代（PermGen）内存大小。
Java堆内存溢出原因分析
Java堆内存溢出原因分析前⾔任何使⽤过基于 Java 的企业级后端应⽤的软件开发者都会遇到过这种低劣、奇怪的报错，这些报错来⾃于⽤户或是测试⼯程师： ng.OutOfMemoryError：Java heap space。
为了弄清楚问题，我们必须返回到算法复杂性的计算机科学基础，尤其是“空间”复杂性。
如果我们回忆，每⼀个应⽤都有⼀个最坏情况特征。
具体来说，在存储维度⽅⾯，超过推荐的存储将会被分配到应⽤程序上，这是不可预测但尖锐的问题。
这导致了堆内存的过度使⽤，因此出现了"内存不够"的情况。
这种特定情况最糟糕的部分是应⽤程序不能修复，并且将崩溃。
任何重启应⽤的尝试 - 甚⾄使⽤最⼤内存（-Xmx option）- 都不是长久之计。
如果不明⽩什么导致了堆使⽤的膨胀或突出，内存使⽤稳定性（即应⽤稳定性）就不能保障。
于是，什么才是更有效的理解关于内存的编程问题的途径？当内存溢出时，明⽩应⽤程序的内存堆和分布情况才能回答这个问题。
在这⼀前提下，我们将聚焦以下⽅⾯：当内存溢出时，获取到 Java 进程中的堆转储。
明⽩应⽤程序正在遭遇的内存问题的类型。
使⽤⼀个堆分析器，可以使⽤ Eclipse MAT 这个优秀的开源项⽬来分析内存溢出的问题。
配置应⽤，为堆分析做准备任何像内存溢出这种⾮确定性的、时有时⽆的问题对于事后的分析都是⼀个挑战。
所以，最好的处理内存溢出的⽅法是让JVM 虚拟机转储⼀份 JVM 虚拟机内存状态的堆⽂件。
Sun HotSpot JVM 有⼀种⽅法可以引导 JVM 转储内存溢出时的堆状态到⼀个⽂件中。
其标准格式为 .hprof 。
所以，为了实现这种操作，向 JVM 启动项中添加 XX:+HeapDumpOnOutOfMemoryError 。
因为内存溢出可能经过很长⼀段时间才会发⽣，向⽣产系统增加这⼀选项也是必须的。
如果堆转储 .hprof ⽂件必须被写在⼀个特定的⽂件系统位置，那么就添加⽬录途径到 XX:HeapDumpPath 。
内存溢出的三种情况及系统配置解决方案
内存溢出的三种情况及系统配置解决方案内存溢出是指程序在运行过程中申请的内存超过了系统所分配的内存空间，导致程序崩溃或出现异常。
内存溢出通常是由于程序设计或系统配置问题引起的。
以下是三种常见的内存溢出情况及相应的系统配置解决方案。
1.单个进程占用内存过大：当一些进程在运行过程中占用的内存超过系统分配的限制时，就会导致内存溢出。
这种情况通常发生在大型应用程序或者后台服务运行时。
解决方案：-增加物理内存：在服务器或计算机中增加物理内存，以满足进程运行所需的内存空间。
-调整虚拟内存：将物理内存和虚拟内存结合使用，允许操作系统使用虚拟内存作为物理内存的扩展，从而提供更大的内存容量。
-优化应用程序：通过优化程序代码、降低内存使用、合理管理资源等方法，减少进程对内存的占用。
2.长时间运行的应用程序产生泄露：有些应用程序在长时间运行后会产生内存泄露的问题，即分配并使用内存后没有将其释放，导致内存占用逐渐增加，最终导致内存溢出。
解决方案：-使用垃圾回收机制：在一些支持垃圾回收的编程语言中，通过垃圾回收机制可以自动释放未使用的内存。
开发人员可以使用这些机制来解决内存泄露问题。
-引入内存监控工具：使用内存监控工具来检测应用程序中的内存泄露，定位并解决导致内存泄露的代码问题。
-定期重启应用程序：定期重启应用程序可以清理内存，防止内存泄露导致内存溢出。
3.大规模并发请求导致内存压力增加：在高并发的情况下，当系统同时处理大量的请求时，每个请求所占用的内存可能累积增加，导致整体内存压力增加，最终出现内存溢出。
解决方案：-加大系统负载均衡能力：通过增加负载均衡器、引入缓存机制等方式，将请求分散到多台服务器上，减少单台服务器的内存压力。
-优化数据库访问：对于一些频繁读写数据库的操作，可以通过合理的数据库设计、使用索引、缓存查询结果等方法，减少对数据库的访问，降低内存压力。
-调整服务器配置：合理设置服务器的最大并发连接数、线程池大小等参数，根据实际需求分配内存资源。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
JAVA内存溢出解决方案1. 内存溢出类型1.1. ng.OutOfMemoryError: PermGen spaceJVM管理两种类型的内存，堆和非堆。
堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。
它和堆不同，运行期内GC不会释放空间。
如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。
PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。
如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
一个最佳的配置例子：(经过本人验证，自从用此配置之后，再未出现过tomcat死掉的情况)set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m-XX:MaxPermSize=256m1.2. ng.OutOfMemoryError: Java heap space第一种情况是个补充，主要存在问题就是出现在这个情况中。
其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。
如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。
所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。
假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。
注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
垃圾回收GC的角色JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：当应用程序线程空闲；另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of memory错误。
因为这个异常根据系统运行环境决定，所以无法预期它何时出现。
根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。
为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。
显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收，一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。
2. JVM内存区域组成简单的说java中的堆和栈；java把内存分两种：一种是栈内存，另一种是堆内存。
2.1. 栈在函数中定义的基本类型变量和对象的引用变量都在函数的栈内存中分配；在函数（代码块）中定义一个变量时，java就在栈中为这个变量分配内存空间，当超过变量的作用域后，java会自动释放掉为该变量所分配的内存空间。
栈调整：参数有+UseDefaultStackSize -Xss256K，表示每个线程可申请256k的栈空间，每个线程都有他自己的Stack。
●优势是存取速度比堆要快；●缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。
2.2. 堆堆内存用来存放由new创建的对象和数组；在堆中分配的内存由java虚拟机的自动垃圾回收器来管理。
java堆分为三个区：New、Old和Permanent。
GC有两个线程：新创建的对象被分配到New区，当该区被填满时会被GC辅助线程移到Old区，当Old 区也填满了会触发GC主线程遍历堆内存里的所有对象。
Old区的大小等于Xmx减去-Xmn。
●优势是可以动态分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的；●缺点就是要在运行时动态分配内存，存取速度较慢。
3. JVM如何设置虚拟内存提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
提示：JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。
默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。
因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。
提示：假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。
简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了提示：注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
提示：设置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old区如果不够大会频繁的触发"主" GC ，大大降低了性能JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
解决方法：手动设置Heap size修改TOMCAT_HOME/bin/catalina.bat在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"4. 内存溢出检测如何查找引起内存泄漏的原因一般有两个步骤:第一是安排有经验的编程人员对代码进行走查和分析，找出内存泄漏发生的位置;第二是使用专门的内存泄漏测试工具进行测试。
第一个步骤在代码走查的工作中，可以安排对系统业务和开发语言工具比较熟悉的开发人员对应用的代码进行了交叉走查，尽量找出代码中存在的数据库连接声明和结果集未关闭、代码冗余等故障代码。
第二个步骤就是检测Java的内存泄漏。
在这里我们通常使用一些工具来检查Java程序的内存泄漏问题。
市场上已有几种专业检查Java内存泄漏的工具，它们的基本工作原理大同小异，都是通过监测Java程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。
开发人员将根据这些信息判断程序是否有内存泄漏问题。
这些工具包括Optimizeit Profiler，JProbe Profiler，JinSight , Rational 公司的Purify 等。
4.1. 性能检查工具使用4.1.1. 定位内存泄漏JProfiler工具主要用于检查和跟踪系统（限于Java开发的）的性能。
JProfiler可以通过时时的监控系统的内存使用情况，随时监视垃圾回收，线程运行状况等手段，从而很好的监视JVM运行情况及其性能。
1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位；2. 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次；3. 应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full GC的时候是不响应客户的交易请求的，非常影响系统性能。
因为开发环境和产品环境会有不同，导致该问题发生有时会在产品环境中发生，通常可以使用工具跟踪系统的内存使用情况，在有些个别情况下或许某个时刻确实是使用了大量内存导致out of memory，这时应继续跟踪看接下来是否会有下降，如果一直居高不下这肯定就因为程序的原因导致内存泄漏。
通常在知道发生内存泄漏之后，第一步是要弄清楚泄漏了什么数据和哪个类的对象引起了泄漏。
一般说来，一个正常的系统在其运行稳定后其内存的占用量是基本稳定的，不应该是无限制的增长的。
同样，对任何一个类的对象的使用个数也有一个相对稳定的上限，不应该是持续增长的。
根据这样的基本假设，我们持续地观察系统运行时使用的内存的大小和各实例的个数，如果内存的大小持续地增长，则说明系统存在内存泄漏，如果特定类的实例对象个数随时间而增长（就是所谓的“增长率”），则说明这个类的实例可能存在泄漏情况。
另一方面通常发生内存泄漏的第一个迹象是：在应用程序中出现了OutOfMemoryError。
在这种情况下，需要使用一些开销较低的工具来监控和查找内存泄漏。
虽然OutOfMemoryError也有可能应用程序确实正在使用这么多的内存；对于这种情况则可以增加JVM可用的堆的数量，或者对应用程序进行某种更改，使它使用较少的内存。
但是，在许多情况下，OutOfMemoryError都是内存泄漏的信号。
一种查明方法是不间断地监控GC的活动，确定内存使用量是否随着时间增加。
如果确实如此，就可能发生了内存泄漏。
4.1.2. 处理内存泄漏的方法一旦知道确实发生了内存泄漏，就需要更专业的工具来查明为什么会发生泄漏。
JVM自己是不会告诉您的。
这些专业工具从JVM获得内存系统信息的方法基本上有两种：JVMTI和字节码技术(byte code instrumentation)。
Java虚拟机工具接口(Java Virtual Machine Tools Interface，JVMTI)及其前身Java虚拟机监视程序接口(Java Virtual Machine Profiling Interface，JVMPI)是外部工具与JVM通信并从JVM收集信息的标准化接口。
字节码技术是指使用探测器处理字节码以获得工具所需的信息的技术。