java也有内存溢出问题，大家分析会有哪些原因

Question

java程序运行时间久了可能一些资源没有及时回收，导致内存消耗增大，所以有些ide会时间长了会越来越慢,主要是垃圾回收的算法的问题。所以出现不足也只能加内存条了。。但是内存泄漏的问题很少。

Answer 1

不能用System.gc()在程序的特定地方来回收垃圾吗?

Answer 2

是内存泄漏更准确一些，尤其是类中的函数管理动态数组，没有及时回收，导致内存耗尽。具体的请看effective java 的item 6。

Answer 3

垃圾回收的算法也是很重要的。 
多种垃圾收集算法有：引用计数 标记清除等
java中的垃圾收集技术主要有 分代技术 复制技术 增量技术 并行复制 等 一个好的算法，要比多加内存更加的有效

Answer 4

1.查看一下你的java解释的参数(-mm,-ms等参数),不行设大点
2.查看一下你的程序,尽量不要频繁的申请/丢弃内存,jvm虽然可以自动回收内存,但很多方法是native的,操作系统的资源jvm是不好干涉的

Answer 5

咱们不编JVM，咱们有什么办法呢？

Answer 6

Leemaasn(呆鸟一号) 
当我们觉得“ Leemaasn(呆鸟一号)“ 是多余的时候，只要不把" Leemaasn(呆鸟一号)" id置为NULL，他就会永远不被回收，这就是JAVA中内存泻露的定义！

Answer 7

为了节约内存，几点建议记得把对象不用的时候置为null
尽量使用primitive数据类型
如果只是访问一个类的某个方法时,可以该方法设计成一个static的方法。
不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。
不要多层复杂的继承，也不要用太过于复杂的构造函数。
可以适当的使用Hashtable，Vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃
等等

Answer 8

可能是你的对象没有释放，对于仍然有指针指向的实例，jvm就不会回收该资源。其实虽然java实现了垃圾回收机制，但是对于内存的管理还是有一套学问的，不然很容易造成内存泄漏。建议看看《effective java》

Answer 9

和你编的程序有关，Java的垃圾回收只是回收那些脱离了作用域的对象（垃圾对象）。
内存溢出有很多地方都能够引起，所以编程时某些地方要特别注意。
具体的东西建议楼主看看此方面的资料。

Answer 10

尽量使用primitive数据类型
如果只是访问一个类的某个方法时,可以该方法设计成一个static的方法。
不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。
不要多层复杂的继承，也不要用太过于复杂的构造函数。
可以适当的使用Hashtable，Vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃

Answer 11

memory leakage是非常频繁的，我在以前的公司SAT部门工作的时候，经常给别的项目组做memory leakage analysis.你要了解JVM对对象管理的7个阶段，明白reachable的概念就行了。你可以看看effective java programming.这本书是java collection framework的作者写的。建议你学学optimizeit或者jprobe,jprofiler.

Answer 12

你说的内存溢出是指什么？OutOfMemoryError？

Answer 13

to totodo(土豆仙)：
你应该首先做profiling，找出内存泄漏的原因，然后相应处理，而不是想当然地“节约内存”。如果一直按照你的那些建议来做，不一定能撞上真正的内存瓶颈，整个程序的设计质量下降倒是真的。>>尽量使用primitive数据类型看看Martin Fowler的《重构》第3章“Bad Smells”，这叫“基本类型狂热症”。只要可能，你就应该用对象取代primitive类型，因为对象是可扩展、可修改、灵活的程序单元。你倒好，建议“尽量用primitive类型”。要是我看到你的程序，首先叫你把那一堆堆的参数组给我重构成参数对象。>>如果只是访问一个类的某个方法时,可以该方法设计成一个static的方法另一个帖子里说过了，要不要static是一个语意的问题，不能由效率来决定。并且static方法要尽量避免使用。如果你把一个方法声明为static，如果你回头又发现这个方法需要多种变化情况，你怎么办？>>不要多层复杂的继承，也不要用太过于复杂的构造函数对象体系也是语意的问题。至于构造函数，你可以看看PicoContainer是如何使用constructor的，然后再来告诉我：构造函数应该如何确定。总而言之，性能是一个大问题，但这不表示你可以随时打着“提高性能”的幌子破坏OOD的优雅。设计越优雅，你越容易找到并修改有性能问题的代码，相反糟糕的设计只会从整体上降低性能。当你要用一个不符合OOD原则的编程方式来追求高性能时，你必须首先证明自己这个行为的合法性：这次修改是否能对性能起到显著的影响？如果你修改的地方仅仅耗用整个系统性能的1%，我就认为你的修改纯粹是在满足自己的某种表现欲。我想每个人都应该记住这个原则：先profiling，再谈性能。没有profiling之前，OOD的原则是不可破坏的。

Answer 14

Schlemiel(维特根斯坦的扇子) 
切，。当你碰到代码非常可读但是运行性能低劣的时候，你就再也不敢说什么“OOD的原则是不可破坏的。“滥用OOD也是应该反对的。

Answer 15

可以看看effective java中关于垃圾回收的那部分,不要完全依赖系统的垃圾回收.
系统的垃圾回收是无法预料的.

Answer 16

to javer6(孤舟万里)：
你说的实际上是“假如代码非常可读但是运行性能低劣”，那么我告诉你，不要妄做假设，尤其是对于你不了解的东西。我的经验告诉我，没有“代码非常可读但是运行性能低劣”这种情况存在，如果设计清晰优雅，你可以轻松地找到系统的性能瓶颈，并且把优化封装在一个很小的范围内。从另一个角度，也可以说你说得对，但是在我不算少的经验里面还从来没有遇到过这样的例子（反例倒是看了不少），所以我敢于继续这样说，敢于继续强调OO的原则。你不妨举一个“代码非常可读但是运行性能低劣”的例子出来看看，也许我就不敢再这么说了。