Java 确实是内存高效的

JVM 是内存高效的，但真正的性能杀手是 Java 的框架。比如 Java 标准库读取一次文件需要用到 File, Stream, TextReader 等好多一次性小对象，这些都需要浪费时间去申请、清理内存，而相比 Go 实现同样的功能，压根不需要这么申请多辅助对象。JVM 分配和回收内存优化再好，也比不过像 Go 这样，从根本上避免分配和回收内存。

hadoop ，spark 强不等于 spring 强，springboot 那内存占用确实挺难绷的

不能这么比，虚拟机内部的管理应该跟 C 写的资源池去比较，不能直接跟系统层面的调用去比

对于 Coding Agent 而言 go 这种不要太友好，型能够，复杂度不好，框架也不重
Java+Spring 哪个不重？再加一堆中间件

现在内存多贵你们知道吗？ 就国内 spring 满天飞这套，从 java 换到别的语言，甚至是 nodejs 能节省多少钱你们知道吗？

“由于 RAM 的成本相对低于 CPU 算力”，以前或许是这样，现在并非

java 本身内存占用就多，再加个 spring 就更多了

问题是 java 好招人啊，我加个机子才多少钱，一个人多少钱。

是是，我小时候他们就这么说的。现在终于有人信啦？

@ryougifujino 以后 RAM 会跌回去的，急啥。

@DeWjjj 现在 ai 时代，你会什么语言根本不重要了，反正都是 ai 写，为什么换更省内存，代码简单方便 review 的 golang 或者极致性能的 rust/c++，java 这个语言在未来注定是被淘汰的，javaer 所谓的生态强大在 ai 面前更是不值一提，重构这种事 ai 最擅长了

@voidmnwzp 怎么可能嘞，java 的集群解决方案，是技术栈选择里面很难被摈弃的一块。

无内鬼，来个 ArrayList<Integer> 笑话

这个结论只适用于大数据场景吧；偏业务侧的应用，木桶短板通常也不在服务侧的 CPU 上，况且你占用的内存越大，访问内存需要的 cpu 周期也是越多的，结果可能是即占了内存，也不省 CPU 。

感觉好像上面已经开始跑题了
单说 Memory Efficient ，我一开始以为指的是“同样一台机器塞下最多有用数据”，但其实看主题是它利用更多内存来降低 CPU 开销。但无论是哪个，我觉得都是成立的。只不过都是需要处理的数据量或业务量够大才能体现。

说实话，作为一个 Javaer ，有时候确实会感觉内存占用多，但基本不会太在意这个。
好不好写才是最重要的。

java 被淘汰是迟早的事情

意思是 C/C++ 就不能自己实现 allcator，就不能用空间换时间？

@DeWjjj “集群解决方案”，你大概率高估这个价值了，ai 时代，那点东西完全不值钱，更有效的编码效率和正确性才是王道，java 在这方面反倒不占优

再加十几个微服务 吃光内存美滋滋

作为普通开发者，你不要跟我讲这些，同样的功能，我用 go 开发，就比 java 内存占用少特别多！！！
PS：作为一个 Java/C 入门，目前 Go/Java 双修的程序员的感想

所以为什么 C/C++不能自己通过 arena 分配内存呢？第 3 点不成立

占用内存多能解释为内存高效？偷换概念

以前一个主机只运行一个应用 应用当然是占用内存越多越好 方便调度

现在是上千个服务一起跑 要求内存不用时需要尽快释放 jvm 那种模式显得不合时宜了

@DeWjjj 现在有 ai 加持 好招人这个优势没那么明显了

@voidmnwzp 从我入行起, 就在讲 "java 这个语言在未来注定是被淘汰的", 10 年过去了, 还在讲. 估计再过个 10 年, 也还会继续讲下去.

工作用语言 基本上自己的项目是绝对不会用的 更喜欢迷你轻量的工具 哪怕性能没那么好甚至差 或一堆需要自己实现的功能 部署快验证除错快 古法编程友好 现有流行的都不轻量

我也不想用 JVM ，但 ElasticSearch 真的香，好像暫時還沒取代品？

@fovecifer 可以试试 java 的 vert.x 内存应该会减少一些。当然绝对数值还是 GO 强，但应该会在同一个量级。

首先高效不高效，跟 java 无关，跟 JVM 有关；其次，JVM 所谓的内存高效，只是在分配小对象的高效，大对象能高效，更别说内存回收了？而且这种高效，C 、C++同样可以做到，难道只有 JVM 才能做到？