V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 45 页 / 共 56 页
回复总数  1114
1 ... 41  42  43  44  45  46  47  48  49  50 ... 56  
2021-08-08 16:42:49 +08:00
回复了 tim0991 创建的主题 Go 编程语言 golang 中多个协程池如何优雅退出
@tim0991 协程池本身就应该自带控制协程数量的属性,否则协程池还不如直接 go 。你看我上面写的也是 pool.Go
2021-08-08 12:14:46 +08:00
回复了 icexin 创建的主题 Go 编程语言 将 Go 程序跑在裸机上之 LibOS
虽然自己用不上,但是很喜欢这感觉,已 star 。
2021-08-08 12:11:30 +08:00
回复了 tim0991 创建的主题 Go 编程语言 golang 中多个协程池如何优雅退出
@tim0991 你只要是整体的别落下 add done,每个 Go 是一个,不管 Go 的 func 里有没有失败跳过,只要 defer done 了就能确保 wg.wait 正常结束,所以,好像不应该有这个困扰
2021-08-08 12:09:58 +08:00
回复了 MakHoCheung 创建的主题 问与答 关于 Java 和 go 高并发的话题
攒币不容易,上次没币了才发现,原来发帖、回复这么费币,得每天签到才行了
2021-08-08 12:08:05 +08:00
回复了 MakHoCheung 创建的主题 问与答 关于 Java 和 go 高并发的话题
@BBCCBB

没有非黑即白,也不狂热。

我从来没说 go gc 完胜 java 。我楼上原文是:
"go 的 gc 整体表现还真是比 java 强,而且特定业务或者框架用 pool 优化,内存、gc 更优"
——注意,是整体表现。

比如引用的知乎帖子,是 2016 年 go1.6,现在已经是 2021 、go1.16 了,10 个大版本了并且中间 1.8 的小对象 gc 更进步了一些。
即使算上 java gc 有很多选择,或者 zgc,golang 还有 pool 一样可以优化更多,我上面有提到自己项目里就用了大量的 pool,内存占用、gc 开销的节约也是非常巨大的,比如压测能省几倍的内存分配,相应的对象少了非常多、gc 当然也省非常多。

"java 内存这块其实和 go 相差无几, 只是现在开发比如套上一层 spring. 框架占的内存是大头, 但是这类框架抽象成都高, 很好用, 能简化开发.. 所以大家依然愿意用. java 和 go 裸写内存占用区别真的不大.."
—— 这又是另一个层次的问题,java 最成功的的地方在于社区强,社区框架、方案一把梭,让小白也能写高级的东西,所以绝大多数项目也是离不开那些占用高的框架,而 go 即使框架,也不占用那么多。如果只用裸 java,还有人用它吗?或者用裸 java 还能让绝大多数人写出稳定高性能的业务代码吗?最好结合线上实际表现来谈语言,而不是都裸语言、理论上对比,毕竟外头很多性能而是对比框架性能,所以既然社区框架方案是绝大多数人的必需品,那就尽量别抛开框架单聊裸 java 了吧,否则咱再把开发效率等其他指标也带上一块对比

另外,java gc 理论上确实最强,我也没否认。但是如果实际业务中表现很差但是按照为了对比 gc 而专门写的例子来对比,那 java 应该是大概率赢了。但是对于 gc 和内存,还有一点请注意:实际业务的服务,java 太吃内存了,同样的功能占用的内存比 go 多太多,响应速度也慢一些,实际效果就是这样。如果同等业务 go 只需要 100M,java 需要 200M,然后对比 gc 非要让 go 也占用到 200M 来跟 java 对比 gc ?那可能确实没什么优势,然而实际的表现就是我说的那样,绝大多数同类业务未对内存占用和 gc 优化过的服务对比,cpu 、内存各项指标 go 都优于 java 很多

我之前的回复,有的地方同步、异步、io 的概念没说的太细,因为直接网页上回复,而且无法编辑修改了。

@x940727

补充一点:
"不是 java 不异步性能差"
——这是最基础的错误认知
我说的同步异步不只是 fd io syscall,而是框架 handler 函数内的,如果同步,比如你操作数据库,线程数量有限,肯定没法快的

另外:
"如果单论语言性能,Java 是要强于 Go 的。"
由于这句,所以我之前的回复可能比较激烈,如果有冒犯,那抱歉了,请见谅,咱们就技术聊技术

还有关于所谓的 "八股文" 也需要解释下:

"Servlet 同步性能依旧不好的原因就是因为在对象的生命周期中做了太多的事情"
"java 如果不异步性能太差,netty 了又 callback hell"
—— 这两点,不管 Servlet 还是 netty,你都考虑下在 handler 里操作数据库的业务,java 的线程数量少、并发量的 CPU 利用率就不够用了,很多 request 要等待,所以还是需要异步。
java 好像也有一些协程库,但是好像还没人敢大规模使用吧?

出于之前的这些探讨,所以才会问你所谓的 "八股文",并且,不是每个人都只是为了面试而背八股文,做底层框架或者分析底层框架的性能影响的方方面面,确实就是需要用这些 "八股文",再并且,即使读够这些 "八股文",纸上得来终觉浅啊兄弟,你如果没去实际玩过这些基础设施的设计、实现、优化,说真的,很多痛点你 get 不到。

基础设施的设计和优化,涉及大量的系统知识,我自己的项目,就是整天要考虑这些 "八股文",有兴趣可以来看下,欢迎交流、指正:
https://github.com/lesismal/nbio
2021-08-08 10:47:24 +08:00
回复了 tim0991 创建的主题 Go 编程语言 golang 中多个协程池如何优雅退出
难道不是

wg.Add(1)
pool.Go(func(){
defer wg.Done()
....
})

吗?
2021-08-07 21:13:24 +08:00
回复了 gidot 创建的主题 程序员 作为十多年的老程序员,突然想分享个想法给大家
言之有理,但不是每只鸟来到这个世界都是为了枪子儿的

越年轻的一代,越在朝着更简洁的沟通方式上发展,我自己年纪大了,不去建议方式了,未来是他们的,顺其自然吧
2021-08-07 17:01:44 +08:00
回复了 xuantedev 创建的主题 Go 编程语言 吐槽一下 golang 的 select 模型,居然不自带超时机制
这根本就不算事:

1. 没人能做到时间的百分百精确
2. 即使是 syacall 的 select/poll/epoll 的 timeout 参数,也可能你本次 loop 刚超时的瞬间、fd 事件就来了,而且超时的瞬间,对于业务而言已经达到了那个可以按超时处理的条件,业务开始处理超时后、超时事件再出现丢弃即可
3. 超时后即使 channel 中又收到了数据而没被读取,也没问题,不是必须读出来才行。另外,chan 也不是必须 close 才会被回收的,所以不用纠结残留相关的问题

并发的边界问题,应该由业务层来保证,是保证指令范围的原子性还是保证过程范围的原子性,要区分清楚
2021-08-06 15:18:50 +08:00
回复了 liuyes 创建的主题 程序员 关于 oracle 数据库的培训,大家有什么好的建议不?
去 IOE,建议放弃 oracle 呢。
2021-08-06 15:12:54 +08:00
回复了 sirnay 创建的主题 Go 编程语言 2021-08-06 Go 微服务框架选谁
2021-08-06 14:48:06 +08:00
回复了 sirnay 创建的主题 Go 编程语言 2021-08-06 Go 微服务框架选谁
大而全的微服务框架不适合中小团队直接拿来用,而大团队自家定制、不太需要用别人的

单就 RPC:
https://colobu.com/2021/08/01/benchmark-of-rpc-frameworks/
帖子中的性能数据可能不准确,最好自己跑那个代码实测下,易用性和各方面优劣可用自行对比
2021-08-03 17:16:20 +08:00
回复了 beginor 创建的主题 硬件 聊聊心目中的完美笔记本
R9000K  感觉不错
2021-08-03 17:11:53 +08:00
回复了 sky3hao 创建的主题 随想 岁月匆匆, 不知不觉已经过了而立之年, 却没有立起来
程序员这行,三十岁,累点的公司,鸡儿都立不起来了
2021-08-01 14:13:15 +08:00
回复了 pythonee 创建的主题 程序员 the little schemer 真是一本神书,相见很晚
有些东西看上去很美。

函数式编程没什么实际营养,当你以为得到了宝贝时,其实是误入了歧途。
2021-07-23 21:35:04 +08:00
回复了 MakHoCheung 创建的主题 问与答 关于 Java 和 go 高并发的话题
@x940727 go 不无敌,但 jvm 确实垃圾。
2021-07-23 21:14:26 +08:00
回复了 MakHoCheung 创建的主题 问与答 关于 Java 和 go 高并发的话题
@x940727 我铜币不够了,你先看下你引用帖子日期吧,其他的我明天说
2021-07-23 20:36:35 +08:00
回复了 MakHoCheung 创建的主题 问与答 关于 Java 和 go 高并发的话题
@x940727

"不了解就是 Go 的 GC 整体比 Java 强"
—— 我不了解 java,但是了解 go,从 java 的 jvm gc 表现看,go 确实强。比如 stw,比如高阶需要手动去调 java gc 策略然而即使调还是 stw 时间比较长,比如 java 吃内存,号称宇宙第一 gc 算法,然而同时也是宇宙第一吃内存怪兽。go 的 gc 自 1.8 以后已经非常强,而且除非代码本身 cpu 打满之类的否则基本不会有所有线程 stw 的情况,并且单个线程 gc 时长也比 java 小,如果这都不算强,那 java 这种号称 gc 算法最强但实际效果拉垮的 gc 赢了我 go 辩不过

"你知道 ElasticSearch 就是 Java 写的吗?"
—— 我上面已经说过了,这是历史原因,go 出生的晚,如果 go 早生,java 就不会如今这么繁荣了。但是话说回来,go 也是站在以前很多语言肩膀商取其精华去其糟粕,比如像 java 的臃肿、嘴炮 gc,go 就当成糟粕而没有采用,而是在 c lisp 之类的简洁基础上更加简洁、借鉴 erlang 之类的并发模型但又不限于 actor 所以让编程姿势更加通用,编译上除了动态链接库那是没办法、静态链接库直接打包到二进制内方便部署。优点很多,不一个一个说了。
ES 是 java 社区较早的积累,而且这种重量的基础设施不只是简单的语言实现、还涉及到整个社区的培养,所以不可能像 F 那样相对轻量的项目可以迅速替换掉 L 那种。
用这个举例,跟你之前用头条招聘举例子是一样的,没有辩论的逻辑性。比如我之前说用 F 替换 L,是能证明 java 有的项目不行所以用 go 取代。但你举出 ES 的例子却不能说明是 go 没能力去取代,而是 go 没有适合的时机去替代,尤其是 ES 这种社区、商业都发展的比较成熟的项目。
单就网络库、框架,我上面问你的那些,我都搞过多年了,java 虽然不熟悉,但是也手撸过 java 的网络库,c/c++/go 的都撸过,进程池、线程池各种框架层的东西、性能优化都是我日常工作内容
2021-07-23 18:24:43 +08:00
回复了 MakHoCheung 创建的主题 问与答 关于 Java 和 go 高并发的话题
@x940727 同步 io 与异步 io 什么区别? select 跟 epoll 什么区别? java 同步库跟 NIO/Netty 什么区别?互联网最早期时进程池模型线程池模型就是同步 io,为什么后来又要搞异步框架?异步 io 你有深入了解过吗?读相关的书或者看优秀项目源码甚至自己手撸过吗? CSAPP,APUE,UNP,内核相关的书,java 高并发网络相关的书,或者其他的优秀的系统层网络层优秀的书有真正认真读过并且理解了吗?
至少从前面几楼你的一些措辞,确实是基础认知的欠缺,如果没有花很多时间在我提问的这些上,建议多研究下,可以等先去确认下自己搞懂了再说
2021-07-23 18:15:00 +08:00
回复了 MakHoCheung 创建的主题 问与答 关于 Java 和 go 高并发的话题
@x940727

"不然并不会比那些很快的同步 Web 框架差多少的"
——这里提到的 "那些很快的同步 Web 框架" 是指哪些框架?恕我见识少,还没听说过有高性能的同步框架(跟之前提到的一样,这里的同步是指同步 IO,不是指 erlang/golang 这种语言级同步)
2021-07-23 18:09:43 +08:00
回复了 MakHoCheung 创建的主题 问与答 关于 Java 和 go 高并发的话题
@x940727

[普通并发量 go 还是有优势,写起来简单,不容易写出瓶颈,java 如果不异步性能太差,netty 了又 callback hell]
——java 我肯定是不熟,但是 netty 异步 callback 应该没问题吧?我前面这句话有什么问题的话,请你指正。
1 ... 41  42  43  44  45  46  47  48  49  50 ... 56  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5143 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 05:54 · PVG 13:54 · LAX 22:54 · JFK 01:54
Developed with CodeLauncher
♥ Do have faith in what you're doing.