本文目录一览：
java有内存溢出吗？如果有是什么情况？
内存溢出是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于虚拟机能提供的最大内存。
所以我们应该明确：存在内存溢出的因不一定导致内存溢出的果。。。
1。JAVA操作文本文件为什么超过3万行就内存益处啊？
PrintWriter out = new PrintWriter(new BufferedWriter(new FileWriter(fileName)));
//PrintWriter out = new PrintWriter(fileName);
//FileOutputStream out = new FileOutputStream(fileName);
while (rs.next()) {
for (int j = 1; j = totalColumn; j++) {
out.write(rs.getObject(j).toString());
out.write("\t");
}
out.write("\n");
out.flush();
}
}
我在代码中 写了 out.flush()用来刷新该流的缓冲; 可是当我的记录数超过3W时就报了内存益处的问题了，难道JAVA不能边读边写吗？还是out这个对象随着指向的fileName文件的边大占用内存也大了吗？？到底怎么来实现用JAVA写更多的数据而不内存益处呢
答案是：就在while(rs.next()) 当rs.next()时内存不断增大，而不是写流的问题，JAVA的ResultSet真是麻烦，而且ResultSet还不能clone(); 所以记得在做项目的时候，经常要设置：jdbc.setMaxRows(100*10000); //设置能容纳100万行记录-----这个就是防止内存泄露的哈------------------- 内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
jdbc.setQueryTimeout(60*30); //设置超时时间是30分钟
2。java中的内存泄露的情况：长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景，通俗地说，就是程序员可能创建了一个对象，以后一直不再使用这个对象，这个对象却一直被引用，即这个对象无用但是却无法被垃圾回收器回收的，这就是java中可能出现内存泄露的情况，例如，缓存系统，我们加载了一个对象放在缓存中(例如放在一个全局map对象中)，然后一直不再使用它，这个对象一直被缓存引用，但却不再被使用。
public class Stack { //长生命周期
private Object[] elements=new Object[10]; //当数组容器中没有东西时是无用的，但是无法回收~~elements是短生命周期
private int size = 0;
public void push(Object e){
ensureCapacity();
elements[size++] = e;
}
public Object pop(){
if( size == 0)
throw new EmptyStackException();
//这里还是引用了，只是指针变位置变化而已，他确实返回了那个对象，但是他却没有断开那个对象的引用，也就是说有两个地方会持有这个对象的引用，调用pop的地方，和elements中
return elements[--size];
}
private void ensureCapacity(){
if(elements.length == size){
Object[] oldElements = elements;
elements = new Object[2 * elements.length+1];
System.arraycopy(oldElements,0, elements, 0, size);
}
}
}
上面的原理应该很简单，假如堆栈加了10个元素，然后全部弹出来，虽然堆栈是空的，没有我们要的东西，但是这是个对象是无法回收的，这个才符合了内存泄露的两个条件(必要条件)：无用，无法回收。
例子1
public class Bad{
public static Stack s=Stack();
static{
s.push(new Object());
s.pop(); //这里有一个对象发生内存泄露
s.push(new Object()); //上面的对象可以被回收了，等于是自愈了，因为引用被覆盖了
}
}
因为是static，就一直存在到程序退出，但是我们也可以看到它有自愈功能，就是说如果你的Stack最多有100个对象，那么最多也就只有100个对象无法被回收其实这个应该很容易理解，Stack内部持有100个引用，最坏的情况就是他们都是无用的，因为我们一旦放新的进取，以前的引用自然消失！
内存泄露的另外一种情况：当一个对象被存储进HashSet集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了，否则，对象修改后的哈希值与最初存储进HashSet集合中时的哈希值就不同了，在这种情况下，即使在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄露。
这是属于： 集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3。代码中存在死循环或循环产生过多重复的对象实体；
4。启动参数内存值设定的过小；
常见的内存泄漏原因及解决方法
（Memory Leak，内存泄漏）
当一个对象已经不需要再使用本该被回收时，另外一个正在使用的对象持有它的引用从而导致它不能被回收，这导致本该被回收的对象不能被回收而停留在堆内存中，这就产生了内存泄漏。
内存泄漏是造成应用程序OOM的主要原因之一。我们知道Android系统为每个应用程序分配的内存是有限的，而当一个应用中产生的内存泄漏比较多时，这就难免会导致应用所需要的内存超过系统分配的内存限额，这就造成了内存溢出从而导致应用Crash。
因为内存泄漏是在堆内存中，所以对我们来说并不是可见的。通常我们可以借助MAT、LeakCanary等工具来检测应用程序是否存在内存泄漏。
1、MAT是一款强大的内存分析工具，功能繁多而复杂。
2、LeakCanary则是由Square开源的一款轻量级的第三方内存泄漏检测工具，当检测到程序中产生内存泄漏时，它将以最直观的方式告诉我们哪里产生了内存泄漏和导致谁泄漏了而不能被回收。
由于单例的静态特性使得其生命周期和应用的生命周期一样长，如果一个对象已经不再需要使用了，而单例对象还持有该对象的引用，就会使得该对象不能被正常回收，从而导致了内存泄漏。
示例：防止单例导致内存泄漏的实例
这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。？？？
例如，有时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，可能会出现如下写法：
这样在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据。虽然这样避免了资源的重复创建，但是这种写法却会造成内存泄漏。因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，从而导致Activity的内存资源不能被正常回收。
解决方法 ：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，就使用Application的Context。
示例：创建匿名内部类的静态对象
1、从Android的角度
当Android应用程序启动时，该应用程序的主线程会自动创建一个Looper对象和与之关联的MessageQueue。当主线程中实例化一个Handler对象后，它就会自动与主线程Looper的MessageQueue关联起来。所有发送到MessageQueue的Messag都会持有Handler的引用，所以Looper会据此回调Handle的handleMessage()方法来处理消息。只要MessageQueue中有未处理的Message，Looper就会不断的从中取出并交给Handler处理。另外，主线程的Looper对象会伴随该应用程序的整个生命周期。
2、 Java角度
在Java中，非静态内部类和匿名类内部类都会潜在持有它们所属的外部类的引用，但是静态内部类却不会。
对上述的示例进行分析，当MainActivity结束时，未处理的消息持有handler的引用，而handler又持有它所属的外部类也就是MainActivity的引用。这条引用关系会一直保持直到消息得到处理，这样阻止了MainActivity被垃圾回收器回收，从而造成了内存泄漏。
解决方法 ：将Handler类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
示例：AsyncTask和Runnable
AsyncTask和Runnable都使用了匿名内部类，那么它们将持有其所在Activity的隐式引用。如果任务在Activity销毁之前还未完成，那么将导致Activity的内存资源无法被回收，从而造成内存泄漏。
解决方法 ：将AsyncTask和Runnable类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，从而造成内存泄漏。
1）比如在Activity中register了一个BraodcastReceiver，但在Activity结束后没有unregister该BraodcastReceiver。
2）资源性对象比如Cursor，Stream、File文件等往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null，而不关闭它们，往往会造成内存泄漏。
3）对于资源性对象在不使用的时候，应该调用它的close()函数将其关闭掉，然后再设置为null。在我们的程序退出时一定要确保我们的资源性对象已经关闭。
4）Bitmap对象不在使用时调用recycle()释放内存。2.3以后的bitmap应该是不需要手动recycle了，内存已经在java层了。
初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的View对象，同时ListView会将这些View对象缓存起来。当向上滚动ListView时，原先位于最上面的Item的View对象会被回收，然后被用来构造新出现在下面的Item。这个构造过程就是由getView()方法完成的，getView()的第二个形参convertView就是被缓存起来的Item的View对象（初始化时缓存中没有View对象则convertView是null）。
构造Adapter时，没有使用缓存的convertView。
解决方法 ：在构造Adapter时，使用缓存的convertView。
我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
解决方法 ：在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。
当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其长期占用的内存也不能被回收，从而造成内存泄露。
解决方法 ：为WebView另外开启一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
1、在涉及使用Context时，对于生命周期比Activity长的对象应该使用Application的Context。凡是使用Context优先考虑Application的Context，当然它并不是万能的，对于有些地方则必须使用Activity的Context。对于Application，Service，Activity三者的Context的应用场景如下：
其中，NO1表示Application和Service可以启动一个Activity，不过需要创建一个新的task任务队列。而对于Dialog而言，只有在Activity中才能创建。除此之外三者都可以使用。
2、对于需要在静态内部类中使用非静态外部成员变量（如：Context、View )，可以在静态内部类中使用弱引用来引用外部类的变量来避免内存泄漏。
3、对于不再需要使用的对象，显示的将其赋值为null，比如使用完Bitmap后先调用recycle()，再赋为null。
4、保持对对象生命周期的敏感，特别注意单例、静态对象、全局性集合等的生命周期。
5、对于生命周期比Activity长的内部类对象，并且内部类中使用了外部类的成员变量，可以这样做避免内存泄漏：
1）将内部类改为静态内部类
2）静态内部类中使用弱引用来引用外部类的成员变量
Android内存泄漏总结
java内存溢出是什么情况？
首先先说一下JVM内存结构问题，JVM为两块：PermanentSapce和HeapSpace，其中\x0d\x0aHeap = }。PermantSpace负责保存反射对象，一般不用配置。JVM的Heap区可以通过-X参数来设定。\x0d\x0a 当一个URL被访问时，内存申请过程如下：\x0d\x0aA. JVM会试图为相关Java对象在Eden中初始化一块内存区域\x0d\x0aB. 当Eden空间足够时，内存申请结束。否则到下一步\x0d\x0aC. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）, 释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区\x0d\x0aD. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区\x0d\x0aE. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）\x0d\x0aF. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”\x0d\x0a\x0d\x0aJVM调优建议:\x0d\x0a\x0d\x0ams/mx：定义YOUNG+OLD段的总尺寸，ms为JVM启动时YOUNG+OLD的内存大小；mx为最大可占用的YOUNG+OLD内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。\x0d\x0aNewSize/MaxNewSize：定义YOUNG段的尺寸，NewSize为JVM启动时YOUNG的内存大小；MaxNewSize为最大可占用的YOUNG内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。\x0d\x0aPermSize/MaxPermSize：定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。\x0d\x0aSurvivorRatio：设置Survivor空间和Eden空间的比例\x0d\x0a\x0d\x0a内存溢出的可能性\x0d\x0a\x0d\x0a1. OLD段溢出\x0d\x0a这种内存溢出是最常见的情况之一，产生的原因可能是：\x0d\x0a1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize)\x0d\x0a2) 程序问题\x0d\x0a单个程序持续进行消耗内存的处理，如循环几千次的字符串处理，对字符串处理应建议使用StringBuffer。此时不会报内存溢出错，却会使系统持续垃圾收集，无法处理其它请求，相关问题程序可通过Thread Dump获取（见系统问题诊断一章）单个程序所申请内存过大，有的程序会申请几十乃至几百兆内存，此时JVM也会因无法申请到资源而出现内存溢出，对此首先要找到相关功能，然后交予程序员修改，要找到相关程序，必须在Apache日志中寻找。\x0d\x0a当Java对象使用完毕后，其所引用的对象却没有销毁，使得JVM认为他还是活跃的对象而不进行回收，这样累计占用了大量内存而无法释放。由于目前市面上还没有对系统影响小的内存分析工具，故此时只能和程序员一起定位。\x0d\x0a\x0d\x0a2. Perm段溢出\x0d\x0a通常由于Perm段装载了大量的Servlet类而导致溢出，目前的解决办法：\x0d\x0a1) 将PermSize扩大，一般256M能够满足要求\x0d\x0a2) 若别无选择，则只能将servlet的路径加到CLASSPATH中，但一般不建议这么处理\x0d\x0a\x0d\x0a3. C Heap溢出\x0d\x0a系统对C Heap没有限制，故C Heap发生问题时，Java进程所占内存会持续增长，直到占用所有可用系统内存\x0d\x0a\x0d\x0a参数说明:\x0d\x0a\x0d\x0aJVM 堆内存（heap）设置选项 \x0d\x0a 参数格式 \x0d\x0a 说 明 \x0d\x0a \x0d\x0a设置新对象生产堆内存（Setting the Newgeneration heap size） \x0d\x0a -XX:NewSize \x0d\x0a 通过这个选项可以设置Java新对象生产堆内存。在通常情况下这个选项的数值为1 024的整数倍并且大于1MB。这个值的取值规则为，一般情况下这个值-XX:NewSize是最大堆内存（maximum heap size）的四分之一。增加这个选项值的大小是为了增大较大数量的短生命周期对象 \x0d\x0a\x0d\x0a增加Java新对象生产堆内存相当于增加了处理器的数目。并且可以并行地分配内存，但是请注意内存的垃圾回收却是不可以并行处理的 \x0d\x0a \x0d\x0a设置最大新对象生产堆内存（Setting the maximum New generation heap size） \x0d\x0a -XX:MaxNewSize \x0d\x0a 通过这个选项可以设置最大Java新对象生产堆内存。通常情况下这个选项的数值为1 024的整数倍并且大于1MB \x0d\x0a\x0d\x0a其功用与上面的设置新对象生产堆内存-XX：NewSize相同\x0d\x0a\x0d\x0a设置新对象生产堆内存的比例（Setting New heap size ratios） \x0d\x0a -XX:SurvivorRatio \x0d\x0a 新对象生产区域通常情况下被分为3个子区域：伊甸园，与两个残存对象空间，这两个空间的大小是相同的。通过用-XX:SurvivorRatio=X选项配置伊甸园与残存对象空间（Eden/survivor）的大小的比例。你可以试着将这个值设置为8，然后监控、观察垃圾回收的工作情况\x0d\x0a\x0d\x0a设置堆内存池的最大值（Setting maximum heap size） \x0d\x0a -Xmx \x0d\x0a 通过这个选项可以要求系统为堆内存池分配内存空间的最大值。通常情况下这个选项的数值为1 024的整数倍并且大于1 MB \x0d\x0a\x0d\x0a一般情况下这个值（-Xmx）与最小堆内存（minimum heap size _Xms）相同，以降低垃圾回收的频度 \x0d\x0a \x0d\x0a取消垃圾回收 \x0d\x0a -Xnoclassgc \x0d\x0a 这个选项用来取消系统对特定类的垃圾回收。它可以防止当这个类的所有引用丢失之后，这个类仍被引用时不会再一次被重新装载，因此这个选项将增大系统堆内存的空间 \x0d\x0a \x0d\x0a设置栈内存的大小 \x0d\x0a -Xss \x0d\x0a 这个选项用来控制本地线程栈的大小，当这个选项被设置的较大（2MB）时将会在很大程度上降低系统的性能。因此在设置这个值时应该格外小心，调整后要注意观察系统的性能，不断调整以期达到最优 \x0d\x0a \x0d\x0a最后说一句，你的机器的连接数设置也至关重要，连接的关闭最好把时间设置的少些，那些连接非常耗费资源。也是引起内存泄露的主要原因。
