要升级系统才能解决，麻了
https://github.com/torvalds/linux/commit/01770a166165738a6e05c3d911fb4609cc4eb416

再查了下，好像是个系统 bug 。
https://github.com/spring-projects/spring-framework/issues/26434

@boobo 就是我把这个字段，存到 redis 中，关系型数据库表里，这个字段留空，提高我入库效率。

这个问题我后来定位出来了，使用 JDK 8
try-with-resource 机制 自动关闭 Files.newOutputStream 生成的流，流正常关闭，堆外内存释放，但是 java.lang.nio.Bits 中的 reserveMemory ，这个内存占用没有被清理，多次操作之后会 OOM 。
改写为 try-with-resource 机制 自动关闭 FileOutputStream 流，就不会有这个问题。
所以推断是 JDK 的 bug

@linyimin520812 用的是 JDK8

java -jar springboot.jar --conf=value 每次变化的就是 value ，但是 spring 项目启动太慢了，想加快这个速度。但是这个 springboot.jar 又不是我的，所以对其内部的改动最好不要很大。

改动需要外置，就是这个 springboot 的程序 jar 包不能动

定位出一个 jdk 的 bug 了，给 oracle 提了 bug ，多久会有邮件回复啊？

我研究了下好像是因为使用方式的问题，multipartFile.getBytes()这种方式会导致直接内存区使用增加，还不会释放，
multipartFile.transferTo(tempFile)这个方法就不会。

multipartFile.getBytes() 这个方法好像是会拷贝一份 byte[]出来，但是这种不是应该在堆内吗，用完了也就 GC 了，咋会导致直接内存区不断增，一直到溢出啊？

// try (OutputStream out = Files.newOutputStream(tempFile.toPath())) {
// out.write(multipartFile.getBytes());
// } catch (IOException e) {
// e.printStackTrace();
// }

这 Spring 的 MultipartFile 是不是有点离谱啊 各种 OOM 用了直接内存区 又不清理

@Nooooobycat 第一层上传直接用的 Spring 的 MultipartFile ， 不是我写的，在这一层就 Direct buffer memory 不够了

@shuson 但是我现在是 我没做限制的呀 理论上不应该是无限大到物理内存的上限吗？

@loongkimc 是的 原来的主干被领导挪了个位置 我怀疑有可能是这个造成的 当然也可能就是我自己傻逼

@nuk 我现在不缺代码，svn 里代码是正常的，只是缺了之前的 commit 记录。。。说实话那些也没啥用，就是不知道公司查不查

有什么好方法吗？

原来的主干给我改名了
我感觉可以先把主干弄下来，然后直接把本地全部覆盖掉，然后提交上去
这次改动改了很多目录结构，就导致冲突比较多才出了问题

svn log 不让改 没权限

解决了，是我呆逼了，ManagerCore 也打包了 所以就出问题了

@rosu 我发现原因好像是 google format 让我导入了好多包 不是这个插件的原因
--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED