一次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 使用流的问题