请去帮助-新手上路获取积分
- 积分
- 11
- 大米
- 颗
- 鳄梨
- 个
- 水井
- 尺
- 蓝莓
- 颗
- 萝卜
- 根
- 小米
- 粒
- 学分
- 个
- 注册时间
- 2022-11-6
- 最后登录
- 1970-1-1
|
本楼: |
👍
100% (9)
|
|
0% (0)
👎
|
全局: |
👍 92% (138) |
|
8% (12) 👎 |
个人的感受。 go本身是编译成standalone app,不需要的library不会链入,生产的文件可以很小,这样你的 docker文件就会很小,节省内存和存储, Java runtime就很占地方,随便写点啥几百兆就没了。 这个问题Java 等到graalvm 把问题都解决了就和go一样了, 从另一个方面看Java可以很方便地做动态加载,go就不行了,编译成native images 另一个问题是reflection很不好处理, graalvm在生成native image过程中会把不用的class全丢掉,这个很难处理reflection,需要developer加入instruction, go天生没这个问题
Go routine很牛,一个 Linux native thread需要8m内存,记得go routine只占2k还是4k, 这样一个server可以handle许多request,记得好像有人做1million的concurrent requests。 传统的Java thread是map到 native thread, 如果用synchronized blocking进行开发
那能处理的就少了许多,需要达到同样的throughtput就只能加server, 这个问题两种方式解决 1 asynchronous programming, 从Java nio 开始到现在的 reactivate programming是这个方向, 再有就是project loom, 现在看估计JDK 21会release, 随着Java virtual thread的引入线程模型和go会一样,以前修炼的asynchronous programming又没用了
纯compute Java和go相差不大 |
|