一次OOM分析-ByteArrayOutPutStream#write引起

本文主要是介绍一次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 codeif (minCapacity - buf.length > 0)grow(minCapacity);
}
private void grow(int minCapacity) {// overflow-conscious codeint 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] 
HeapPSYoungGen      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 1058816Kclass space    used 1064K, capacity 1120K, committed 1280K, reserved 1048576K