TLDR:
 |
1
xuld Jun 13
JVM 是内存高效的，但真正的性能杀手是 Java 的框架。比如 Java 标准库读取一次文件需要用到 File, Stream, TextReader 等好多一次性小对象，这些都需要浪费时间去申请、清理内存，而相比 Go 实现同样的功能，压根不需要这么申请多辅助对象。JVM 分配和回收内存优化再好，也比不过像 Go 这样，从根本上避免分配和回收内存。
|
 |
2
defaw Jun 13
hadoop ，spark 强不等于 spring 强，springboot 那内存占用确实挺难绷的
|
 |
3
cybort Jun 13 via Android  1
不能这么比，虚拟机内部的管理应该跟 C 写的资源池去比较，不能直接跟系统层面的调用去比
|
 |
4
zls3201 Jun 13
对于 Coding Agent 而言 go 这种不要太友好，型能够，复杂度不好，框架也不重
Java+Spring 哪个不重？再加一堆中间件 |
 |
5
daysv Jun 13
现在内存多贵你们知道吗？ 就国内 spring 满天飞这套，从 java 换到别的语言，甚至是 nodejs 能节省多少钱你们知道吗？
|
 |
6
ryougifujino Jun 13
“由于 RAM 的成本相对低于 CPU 算力”，以前或许是这样，现在并非
|
 |
7
NO9527 Jun 14
java 本身内存占用就多，再加个 spring 就更多了
|
 |
8
DeWjjj PRO 问题是 java 好招人啊，我加个机子才多少钱，一个人多少钱。
|
 |
9
kneo Jun 14 via Android
是是，我小时候他们就这么说的。现在终于有人信啦？
|
 |
10
likooo125802023 Jun 14
@ryougifujino 以后 RAM 会跌回去的，急啥。
|
 |
11
voidmnwzp Jun 14 via iPhone
@DeWjjj 现在 ai 时代，你会什么语言根本不重要了，反正都是 ai 写，为什么换更省内存，代码简单方便 review 的 golang 或者极致性能的 rust/c++，java 这个语言在未来注定是被淘汰的，javaer 所谓的生态强大在 ai 面前更是不值一提，重构这种事 ai 最擅长了
|
 |
13
wakarimasen Jun 14 via Android
无内鬼，来个 ArrayList<Integer> 笑话
|
 |
14
kkbblzq Jun 14
这个结论只适用于大数据场景吧；偏业务侧的应用，木桶短板通常也不在服务侧的 CPU 上，况且你占用的内存越大，访问内存需要的 cpu 周期也是越多的，结果可能是即占了内存，也不省 CPU 。
|
 |
15
dcsuibian Jun 14
感觉好像上面已经开始跑题了
单说 Memory Efficient ，我一开始以为指的是“同样一台机器塞下最多有用数据”，但其实看主题是它利用更多内存来降低 CPU 开销。但无论是哪个，我觉得都是成立的。只不过都是需要处理的数据量或业务量够大才能体现。 说实话，作为一个 Javaer ，有时候确实会感觉内存占用多，但基本不会太在意这个。 好不好写才是最重要的。 |
 |
16
lolo1 Jun 14 via Android
java 被淘汰是迟早的事情
|
 |
17
unused Jun 14 via Android
意思是 C/C++ 就不能自己实现 allcator，就不能用空间换时间？
|
 |
19
mightofcode Jun 14
再加十几个微服务 吃光内存美滋滋
|
 |
20
fovecifer Jun 14
作为普通开发者，你不要跟我讲这些，同样的功能，我用 go 开发，就比 java 内存占用少特别多！！！
PS：作为一个 Java/C 入门，目前 Go/Java 双修的程序员的感想 |
 |
21
charles0 Jun 14
所以为什么 C/C++不能自己通过 arena 分配内存呢？第 3 点不成立
|
 |
22
Domado Jun 14
占用内存多能解释为内存高效？偷换概念
|
 |
23
roundgis Jun 14 via Android
以前一个主机只运行一个应用 应用当然是占用内存越多越好 方便调度
现在是上千个服务一起跑 要求内存不用时需要尽快释放 jvm 那种模式显得不合时宜了 |
 |
26
james122333 Jun 14 via Android
工作用语言 基本上自己的项目是绝对不会用的 更喜欢迷你轻量的工具 哪怕性能没那么好甚至差 或一堆需要自己实现的功能 部署快验证除错快 古法编程友好 现有流行的都不轻量
|
 |
27
kennylam777 Jun 14 via Android
我也不想用 JVM ，但 ElasticSearch 真的香，好像暫時還沒取代品？
|
 |
29
kivmi Jun 14
首先高效不高效，跟 java 无关，跟 JVM 有关；其次，JVM 所谓的内存高效，只是在分配小对象的高效，大对象能高效，更别说内存回收了？而且这种高效，C 、C++同样可以做到，难道只有 JVM 才能做到？
|
 |
30
seedhk Jun 15
@wakarimasen 这是什么梗
|
 |
34
Ipsum Jun 15
啊，想起了我司那个银行流水上报系统。就是个简单的爬虫，用的 spring boot 的微服务框架，居然要 20G 内存。
|
|
35
fovecifer Jun 15
@byte10 早就不用 spring 那套了，用了好几年的 vertx,内存问题上确实有提升。但是跟你说的一样，绝对数值上还是 go 强。我始终坚持 java 主要还是生态，有些东西没有合适的替代品。
|
 |
36
byte10 Jun 16
@fovecifer Quarkus底层也是 vertx ，而且很容易用 graalvm 去编译成可执行文件，内存应该会更低一些。不过运行起来后，估计也是差不多。
vertx 的设计真的神啊，天生就是适合做微服务，可惜啊实际项目都是 spring😂，我很喜欢 vertx 这玩意。虚拟线程出来之后，可以直接封神了。 |
 |
39
cubecube Jun 22
RAM 比 CPU 廉价这个前提现在不存在了。。新的服务器，RAM 比 CPU 贵不少！！
|
 |
40
sagaxu Jun 28
@byte10 我最近在一个使用 Kotlin 语言的小项目中，分别用 springboot 和 vert.x 做 API 服务，各自进行 nativeCompile 编译 binary ，两者在 native 后差距不大，vert.x 稍胜一筹，内存占用比 Go 还是高一些，编译时间就要比 Go 高一个数量级了。
springboot 有了虚拟线程之后，vert.x 的性能优势还在，但没有 multithreading vs reactive 这种架构带来的降维打击式的巨大差距了。 vert.x + kotlin coroutine ，开发心智负担也很小，尤其是有了虚拟线程之后，可以在 coroutine 中调用阻塞函数(withTimeout 类方法在阻塞时无法工作)，只借用 kotlin 的 coroutien 的结构化并发管理，不再需要 executeBlocking 缝合了。如果完全不用 coroutine ，直接.await()也变得可用了，比以前借助 quasar 实现的同步编码方式好太多了。 vert.x 目前(5.1 为止)还有多个涉及虚拟线程的 issue ，可能还需要一年左右才能成熟无问题。quarkus 我也试过，感觉就是个 vertxboot ，用户基数有点小，vert.x 5.0 发布一年多了，quarkus 还没完成 5.0 的适配，迁移工作量还不小，可能 2027 才发布，2027 年末甚至 2028 才可用。 https://github.com/quarkusio/quarkus/issues/51959 JVM 可能要等 valhalla 成熟后，内存占用才能再提升一档，估计快了，2030 年之前吧。native aot 这块儿，dotnet 其实做的很不错，编译速度要快的多，内存占用也低的多，性能和打包后的 binary 体积也能跟 Go 比一比。 |
|
41
byte10 Jun 29
@sagaxu 专业！
请教下 quarkus 迁移 vert.x-5.0 的难度是啥，4.X 版本也有虚拟线程吧，迁移过来应该不难吧？我很早之前就用到它的虚拟线程，好像还写了一个 await 的工具类，在虚拟线程中使用。 |
|
43
byte10 6 days ago
@pcloves 没研究过哦。vertx 4.0 就可以用使用虚拟线程了，就是核心 vertical 那边可以用虚拟线程，配合 feture 的，后续都可以玩同步编程了。
|
Select Language