真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

Java編程常見內(nèi)存溢出異常的示例分析

小編給大家分享一下Java編程常見內(nèi)存溢出異常的示例分析,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),武陵企業(yè)網(wǎng)站建設(shè),武陵品牌網(wǎng)站建設(shè),網(wǎng)站定制,武陵網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,武陵網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力??沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿,時(shí)刻以成就客戶成長(zhǎng)自我,堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

Java 堆是用來存儲(chǔ)對(duì)象實(shí)例的, 因此如果我們不斷地創(chuàng)建對(duì)象, 并且保證 GC Root 和創(chuàng)建的對(duì)象之間有可達(dá)路徑以免對(duì)象被垃圾回收, 那么當(dāng)創(chuàng)建的對(duì)象過多時(shí), 會(huì)導(dǎo)致 heap 內(nèi)存不足, 進(jìn)而引發(fā) OutOfMemoryError 異常.

/**
 * @author xiongyongshun
 * VM Args: java -Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError
 */
public class OutOfMemoryErrorTest {
  public static void main(String[] args) {
    List list = new ArrayList<>();
    int i = 0;
    while (true) {
      list.add(i++);
    }
  }
}

上面是一個(gè)引發(fā) OutOfMemoryError 異常的代碼, 我們可以看到, 它就是通過不斷地創(chuàng)建對(duì)象, 并將對(duì)象保存在 list 中防止其被垃圾回收, 因此當(dāng)對(duì)象過多時(shí), 就會(huì)使堆內(nèi)存溢出。

通過 java -Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError 我們?cè)O(shè)置了堆內(nèi)存為 10 兆, 并且使用參數(shù) -XX:+HeapDumpOnOutOfMemoryError 讓 JVM 在發(fā)生 OutOfMemoryError 異常時(shí)打印出當(dāng)前的內(nèi)存快照以便于后續(xù)分析.

編譯運(yùn)行上述代碼后, 會(huì)有如下輸出:

>>> java -Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError com.test.OutOfMemoryErrorTest                                              16-10-02 23:35
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid1810.hprof ...
Heap dump file created [14212861 bytes in 0.125 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3210)
    at java.util.Arrays.copyOf(Arrays.java:3181)
    at java.util.ArrayList.grow(ArrayList.java:261)
    at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
    at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
    at java.util.ArrayList.add(ArrayList.java:458)
    at com.test.OutOfMemoryErrorTest.main(OutOfMemoryErrorTest.java:15)

Java 棧 StackOverflowError

我們知道, JVM 的運(yùn)行時(shí)數(shù)據(jù)區(qū)中有一個(gè)叫做 虛擬機(jī)棧 的內(nèi)存區(qū)域, 此區(qū)域的作用是: 每個(gè)方法在執(zhí)行時(shí)都會(huì)創(chuàng)建一個(gè)棧幀, 用于存儲(chǔ)局部變量表, 操作數(shù)棧, 方法出口等信息.

因此我們可以創(chuàng)建一個(gè)無限遞歸的遞歸調(diào)用, 當(dāng)遞歸深度過大時(shí), 就會(huì)耗盡??臻g, 進(jìn)而導(dǎo)致了 StackOverflowError 異常.

下面是具體的代碼:

/**
 * @author xiongyongshun
 * VM Args: java -Xss64k
 */
public class OutOfMemoryErrorTest {
  public static void main(String[] args) {
    stackOutOfMemoryError(1);
  }

  public static void stackOutOfMemoryError(int depth) {
    depth++;
    stackOutOfMemoryError(depth);
  }
}

當(dāng)編譯運(yùn)行上述的代碼后, 會(huì)輸出如下異常信息:

Exception in thread "main" java.lang.StackOverflowError
  at com.test.OutOfMemoryErrorTest.stackOutOfMemoryError(OutOfMemoryErrorTest.java:27)

方法區(qū)內(nèi)存溢出

注意, 因?yàn)?nbsp;JDK8 已經(jīng)移除了永久代, 取而代之的是 metaspace, 因此在 JDK8 中, 下面兩個(gè)例子都不會(huì)導(dǎo)致 java.lang.OutOfMemoryError: PermGen space 異常.

運(yùn)行時(shí)常量池溢出

在 Java 1.6 以及之前的 HotSpot JVM 版本時(shí), 有永久代的概念, 即 GC 的分代收集機(jī)制是擴(kuò)展至方法區(qū)的. 在方法區(qū)中, 有一部分內(nèi)存是用于存儲(chǔ)常量池, 因此如果代碼中常量過多時(shí), 就會(huì)耗盡常量池內(nèi)存, 進(jìn)而導(dǎo)致內(nèi)存溢出.那么如何添加大量的常量到常量池呢? 這時(shí)就需要依靠 String.intern() 方法了. String.intern() 方法的作用是: 若此 String 的值在常量池中已存在, 則這個(gè)方法返回常量池中對(duì)應(yīng)字符串的引用; 反之將此 String 所包含的值添加到常量池中, 并返回此 String 對(duì)象的引用. 在 JDK 1.6 以及之前的版本中, 常量池分配在永久代中, 因此我們可以通過設(shè)置參數(shù) “-XX:PermSize” 和 “-XX:MaxPermSize” 來間接限制常量池的大小.

注意, 上面所說的 String.intern() 方法和常量池的內(nèi)存分布僅僅針對(duì)于 JDK 1.6 及之前的版本, 在 JDK 1.7 或以上的版本中, 由于去除了永久代的概念, 因此內(nèi)存布局稍有不同.

下面是實(shí)現(xiàn)常量池內(nèi)存溢出的代碼例子:

/**
 * @author xiongyongshun
 * VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M 
 */
public class RuntimeConstantPoolOOMTest {
  public static void main(String[] args) {
    List list = new ArrayList();
    int i = 0;
    while (true) {
      list.add(String.valueOf(i++).intern());
    }
  }
}

我們看到, 這個(gè)例子中, 正是使用了 String.intern() 方法, 向常量池中添加了大量的字符串常量, 因而導(dǎo)致了常量池的內(nèi)存溢出.

我們通過 JDK1.6 編譯并運(yùn)行上面的代碼, 會(huì)有如下輸出:

Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
    at java.lang.String.intern(Native Method)
    at com.test.RuntimeConstantPoolOOMTest.main(RuntimeConstantPoolOOMTest.java:16)

需要注意的是, 如果通過 JDK1.8 來編譯運(yùn)行上面代碼的話, 會(huì)有如下警告, 并且不會(huì)產(chǎn)生任何的異常:

>>> java -XX:PermSize=10M -XX:MaxPermSize=10M com.test.RuntimeConstantPoolOOMTest                                                 16-10-03 0:23
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=10M; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=10M; support was removed in 8.0

方法區(qū)的內(nèi)存溢出

方法區(qū)作用是存放 Class 的相關(guān)信息, 例如類名, 類訪問修飾符, 字段描述, 方法描述等. 因此如果方法區(qū)過小, 而加載的類過多, 就會(huì)造成方法區(qū)的內(nèi)存溢出.

//VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M
public class MethodAreaOOMTest {
  public static void main(String[] args) {
    while (true) {
      Enhancer enhancer = new Enhancer();
      enhancer.setSuperclass(MethodAreaOOMTest.class);
      enhancer.setUseCache(false);
      enhancer.setCallback(new MethodInterceptor() {
        public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
          return methodProxy.invokeSuper(o, objects);
        }
      });

      enhancer.create();
    }
  }
}

上面的代碼中, 我們借助 CGlib 來動(dòng)態(tài)地生成大量的類, 在 JDK6 下, 運(yùn)行上面的代碼會(huì)產(chǎn)生 OutOfMemoryError: PermGen space 異常:

/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java -jar -XX:PermSize=10M -XX:MaxPermSize=10M target/Test-1.0-SNAPSHOT.jar

輸出結(jié)果如下:

Caused by: java.lang.OutOfMemoryError: PermGen space
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
    ... 11 more

MetaSpace 內(nèi)存溢出

在 方法區(qū)的內(nèi)存溢出 內(nèi)存溢出一節(jié)中, 我們提到, JDK8 沒有了永久代的概念, 因此那兩個(gè)例子在 JDK8 下沒有實(shí)現(xiàn)預(yù)期的效果. 那么在 JDK8 下, 是否有類似方法區(qū)內(nèi)存溢出之類的錯(cuò)誤呢? 當(dāng)然有的. 在 JDK8 中, 使用了 MetaSpace 的區(qū)域來存放 Class 的相關(guān)信息, 因此當(dāng) MetaSpace 內(nèi)存空間不足時(shí), 會(huì)拋出 java.lang.OutOfMemoryError: Metaspace 異常.

我們還是以上面提到的例子為例:

//VM Args: -XX:MaxMetaspaceSize=10M
public class MethodAreaOOMTest {
  public static void main(String[] args) {
    while (true) {
      Enhancer enhancer = new Enhancer();
      enhancer.setSuperclass(MethodAreaOOMTest.class);
      enhancer.setUseCache(false);
      enhancer.setCallback(new MethodInterceptor() {
        public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
          return methodProxy.invokeSuper(o, objects);
        }
      });

      enhancer.create();
    }
  }
}

此例子的代碼部分沒有改動(dòng), 唯一的區(qū)別是我們需要使用 JDK8 來運(yùn)行這段代碼, 并且設(shè)著參數(shù) -XX:MaxMetaspaceSize=10M, 這個(gè)參數(shù)告訴 JVM Metaspace 的最大大小是 10M.

接著我們使用 JDK8 來編譯運(yùn)行這個(gè)例子, 輸出如下異常:

>>> java -jar -XX:MaxMetaspaceSize=10M target/Test-1.0-SNAPSHOT.jar
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
  at net.sf.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:345)
  at net.sf.cglib.proxy.Enhancer.generate(Enhancer.java:492)
  at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:114)
  at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:291)
  at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:480)
  at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:305)
  at com.test.MethodAreaOOMTest.main(MethodAreaOOMTest.java:22)

以上是“Java編程常見內(nèi)存溢出異常的示例分析”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對(duì)大家有所幫助,如果還想學(xué)習(xí)更多知識(shí),歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道!


分享文章:Java編程常見內(nèi)存溢出異常的示例分析
本文路徑:http://weahome.cn/article/gihdgi.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部