一次OOM分析-ByteArrayOutPutStream#write引起

本文產生的原因

上傳一個大文件文件的時候報了OOM

查看代碼

以前的上傳代碼中使用了

URL url = new **URL**(urlStr);
conn = (HttpURLConnection) url.openConnection();
....省略
out = conn.getOutputStream();
conn.setRequestMethod("POST");
conn.connect();
byte[] bufferOut = new byte[1024 * 1024];
int bytes = 0;
 while ((bytes = in.read(bufferOut)) != -1) {
     out.write(bufferOut, 0, bytes);
 }

查看源碼

順着OOM時候的堆棧，查看源碼。
write的時候 PosterOutputStream作爲ByteArrayOutPutStream的子類，直接使用了super.write，所以直接查看ByteArrayOutPutStream#write(byte b[], int off, int len)即可

write的時候，將目標數據（數組）寫入到ByteArrayOutputStream#buf中，若buf不夠大，則擴容至2倍。
注意：擴容時，需要3倍的內存才能成功擴容。

ByteArrayOutPutStream#write源碼

public synchronized void write(byte b[], int off, int len) {
    if ((off < 0) || (off > b.length) || (len < 0) ||
        ((off + len) - b.length > 0)) {
        throw new IndexOutOfBoundsException();
    }
    **ensureCapacity**(count + len);
    System.arraycopy(b, off, buf, count, len);
    count += len;
}
 private void ensureCapacity(int minCapacity) {
    // overflow-conscious code
    if (minCapacity - buf.length > 0)
        grow(minCapacity);
}
private void grow(int minCapacity) {
    // overflow-conscious code
    int oldCapacity = buf.length;
    int newCapacity = oldCapacity << 1;//增長爲2倍
    if (newCapacity - minCapacity < 0)
        newCapacity = minCapacity;
    if (newCapacity - MAX_ARRAY_SIZE > 0)
        newCapacity = hugeCapacity(minCapacity);
    buf = Arrays.copyOf(buf, newCapacity);//新的數組最少需要舊數組兩倍的內存
}

爲何會使用到PosterOutputStream

getOutPutStream的時候，若不是streaming，就使用PosterOutputStream。
#TODO 鏈接

public boolean streaming() {
        return this.fixedContentLength != -1 || this.fixedContentLengthLong != -1L || this.chunkLength != -1;
    }

解決方式ByteArrayOutPutStream#write引起的OOM

1.設置超大內存。按照最壞情況估計，設置爲最大上傳文件的3倍內存。（ps:這裏僅僅考慮了擴容時的內存，需要再添加一些內存爲其他數據）
2.使用conn.setFixedLengthStreamingMode或者conn.setChunkedStreamingMode，避免使用ByteArrayOutPutStream。ps:需要目標服務器支持。

本地測試

java版本：java8
啓動參數：-XX:+UseConcMarkSweepGC -Xmx400m -Xms400m -Xmn30m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:G:/學習/gclog.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=G:/學習/dump.hprof

參數說明：
-Xmx400m -Xms400m 最大堆內存 400M,最小堆內存400M， 老年代=400m-30m=370m
-Xmn30m 新生代30M 默認 SurvivorRatio 8, eden:s0:s1爲8:1:1,所以新生代爲9,即30m*0.9=27m
MetaspaceSize 爲本地內存。 非堆。

打算上傳的a.apk只有345M ，堆內存400M,老年代370M,看起來是夠的

    public static void main(String[] args) throws IOException {
        File file = new File("G:/學習/a.apk");
        System.out.println(file.length()/1024/1024);
        FileInputStream fileInputStream = new FileInputStream(file);
        OutputStream out = new ByteArrayOutputStream();
        byte[] bytesRead = new byte[1024*1024*8];
        int n = 0;
        int times = 0;
        while ((n = fileInputStream.read(bytesRead)) != -1) {
            try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
            System.out.println(++times*8 + "m");
            out.write(bytesRead, 0, n);
        }
        System.out.println("----"+((ByteArrayOutputStream) out).size()/1024/1024);
    }

使用jmap -heap jpsid查看堆內存

使用JVisualVM查看堆內存增長

在128M 即將申請256M內存之前，先嚐試回收內存。回收後
137.8M, 370-137.8=242.2M， 老年代仍小於256M ，因此OOM。

gc日誌
gclog.log中
[ParOldGen: 253984K->141506K(378880K) 可以看出，老年代內存從248M回收到了137.8M。

2019-10-23T16:57:15.205+0800: 51.679: [Full GC (Allocation Failure) [PSYoungGen: 2312K->0K(27136K)] [ParOldGen: 253984K->141506K(378880K)] 256296K->141506K(406016K), [Metaspace: 9290K->9290K(1058816K)], 0.0327092 secs] [Times: user=0.08 sys=0.00, real=0.03 secs] 
2019-10-23T16:57:15.238+0800: 51.712: [GC (Allocation Failure) [PSYoungGen: 0K->0K(27136K)] 141506K->141506K(406016K), 0.0109249 secs] [Times: user=0.05 sys=0.00, real=0.01 secs] 
2019-10-23T16:57:15.249+0800: 51.723: [Full GC (Allocation Failure) [PSYoungGen: 0K->0K(27136K)] [ParOldGen: 141506K->141136K(378880K)] 141506K->141136K(406016K), [Metaspace: 9290K->9147K(1058816K)], 0.0228731 secs] [Times: user=0.05 sys=0.00, real=0.02 secs] 
Heap
 PSYoungGen      total 27136K, used 707K [0x00000000fe200000, 0x0000000100000000, 0x0000000100000000)
  eden space 23552K, 3% used [0x00000000fe200000,0x00000000fe2b0c38,0x00000000ff900000)
  from space 3584K, 0% used [0x00000000ffc80000,0x00000000ffc80000,0x0000000100000000)
  to   space 3584K, 0% used [0x00000000ff900000,0x00000000ff900000,0x00000000ffc80000)
 ParOldGen       total 378880K, used 141136K [0x00000000e7000000, 0x00000000fe200000, 0x00000000fe200000)
  object space 378880K, 37% used [0x00000000e7000000,0x00000000ef9d4238,0x00000000fe200000)
 Metaspace       used 9159K, capacity 9426K, committed 9984K, reserved 1058816K
  class space    used 1064K, capacity 1120K, committed 1280K, reserved 1048576K

相關資料

OutputStream OutOfMemoryError when sending HTTP
Understanding the Java Garbage Collection Log
URLConnection 使用流的問題