@cdlnls 这个问题确实无解，只能寻求个所谓的最佳实践，还有可能应用会操作 direct memory 。但是 dump 还是得要的，看起来只能牺牲一些内存了，MaxRAMPercentage=25.0 是默认值，一般会设置 MaxRAMPercentage=70.0 左右。

@cheng6563 不考虑 dump 之后的参数。limit 设置的足够大，会不会造成资源浪费

都不用，自己写 Dockerfile 打包，一把都集成在 ci 里边

缓存就用 redis 吧，多实例也能生效

如果是为了效率的话，web 项目，kotlin + spring 确实不错

spring vs spring 也有很大区别，光罗列名词，看不出来的

把整个项目的需求拿来讲，不一定要回答你做的，别人做的你理解了，也是你的

小公司，有人开了公网，没加认证，被人写爆了。。。

@Haku 我说的容器，当成 k8s 里边的 pod 理解，把 java 和 python 放到一个 pod 里边，docker 的话就是一个 compose ，设置下网络策略。在一个 pod 里边用 http 访问。不过按你这描述，容器应该也不会让你们用。

@Haku java 不是你们写的，就难办了，graalvm 估计调用方也不会用，还要安装新的 jdk 环境，按这描述只能进程间通信了吧

容器也不行吗

graalvm 试试，虽然我没用过

@gitrebase 最外层打印日志也有点问题，如果调用链太深或者封装的 error 太多，还是不方便直接看出错误源，error 不自带调用栈，我觉得这是最难接受的

@wkong 你去看看多少代码 if err!=nil 直接 return 的，一个业务那么多 error ，怎么确定哪个是底层已经打印日志了。
调用其他同事的方法，难道还要去看看他写的源码，error 返回的是啥，看看 fmt.errorf("")里边写的啥？

1. go 的 error 类型太弱，只能靠字符串判断
2. 多层 error ，如果直接返回，溯源太难（原生 error 无调用栈），如果追加信息，就会有 1 的问题，是什么错误类型难判断
3. 如果不介意多代码，java 完全可以全部是 checked exception ，自带类型和调用栈

戴森吹风机，差不多这个价格