买 mac mini 吧，其他都风扇吵死的

淘宝假货太多了，这种基本 100%假，还有什么天猫国际自营，也是，一堆假货

别买 neo ，别的我不知道，反正 neo 户外飞不了

@chendl111 我们相当于是一个中台，我们部门没有运维，都是开发部署，连需求都是开发来写。我们是传统行业，其实公司规模还蛮大的。中台对接 5-6 业务组，每个业务组有开发、测试、性能测试等环境，每个环境的证书、配置都不一样，CI 是可以，CD 就很难。

我的就是 mac ，然后用 dockerdesktop 启动了 k8s 但是我的端口永远开不开，外部连不到我本机的 k8s 集群，本地可以连本地

要升级系统才能解决，麻了
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 记录。。。说实话那些也没啥用，就是不知道公司查不查