@iyaozhen 欢迎来跑数据对比下，包括 cloudwego/kitex-benchmark，我都有 pr 和 issue：
https://github.com/lesismal/go-net-benchmark/issues/1

@xuanbg http 性能比较差，http 不能推送，无法满足很多业务。即使"http 之类的应用层协议” 是指包括了 websocket 等协议，仍然面临着框架选择的问题，比如 go 的 websocket 协议，知名的 gorilla/websocket 仍然需要自行封装读写、melody 甚至存在并发 bug 可能导致宕机并且作者已经杳无音讯。所以不适合用做业务的思维去回答技术选型的问题，当某一天你成长为更高阶的新时代农民工、负责这些事情的时候，也会面临同样的选型问题。

介绍下自己俩库，arpc 和 nbio：
https://www.v2ex.com/t/794435#reply0

这两个库可以覆盖绝大多数应用业务场景，比如：RPC 、IM 、游戏、广播 /推送服务、其他自家功能交互等。
支持 tcp/kcp/quic/websocket 各种协议作为传输载体。
单机连接数量不特别大比如 10k-100k 这种级别的（普通人眼里觉得 10k 已经算大了，但是对于网络框架而言，这个量级很小，那些性能差的脚本语言就不要来讨论性能了），配置能扛得住就默认标准库方案。
海量并发比如单机 100k-1000k 这种级别的，可以 arpc+nbio，照样能扛。
这个领域里，一是性能，二是易用性，有兴趣的同学可以自行对比。
关于性能，有兴趣的同学可以去看下鸟窝老师和字节同学的 benchmark 库，硬件不同压测结果可能存在差异，所以有兴趣的同学不要看仓库文档展示的结果，请自己机器实测看效果：
github.com/rpcxio/rpcx-benchmark
github.com\cloudwego\kitex-benchmark

@abersheeran 没办法，"粘包" 虽然是错误的概念，但已约定俗成，懂的人只是用这个词沟通问题

足够满足楼主和各位各种业务场景：
https://github.com/lesismal/arpc

pool 优化里也可以把那个 initedGameStart 去掉，*v = initedGameStart 就换成普通的赋值，或者放在 pool.Get 的 New 里，不需要每次都初始化这个 LayerPosition 字段，取决于实际需要

### 一般写法，工厂方法

```golang
package main

type GameStart struct {
cloudNumber int
gameStartLayers [8]*ebiten.Image
layerPosition [8][2]float64
menuList [3]*Menu
}

func NewGameStart() *GameStart {
return &GameStart{
cloudNumber: 3,
layerPosition: [8][2]float64{
{0, 0}, {0, 0}, {0, 230}, {0, 250},
{0, 250}, {0, 0}, {0, 0}, {0, 0},
},
}
}

func main() {
var gameStart = NewGameStart()
}
```


### 如果需要 pool 优化，还可以：
```golang
package main

import (
"sync"
)

var initedGameStart = GameStart{
cloudNumber: 3,
layerPosition: [8][2]float64{
{0, 0}, {0, 0}, {0, 230}, {0, 250},
{0, 250}, {0, 0}, {0, 0}, {0, 0},
},
}

var gameStartPool = sync.Pool{
New: func() interface{} {
return &GameStart{}
},
}

type GameStart struct {
cloudNumber int
gameStartLayers [8]*ebiten.Image
layerPosition [8][2]float64
menuList [3]*Menu
}

func (v *GameStart) Release() {
// maybe you want to release gameStartLayers and menuList here
// ...

gameStartPool.Put(v)
}

func NewGameStart() *GameStart {
v := gameStartPool.Get().(*GameStart)
*v = initedGameStart
return v
}

func main() {
var gameStart = NewGameStart()
defer gameStart.Release()
}
```

@kksco 社交太费时间了，前几天有几位加微信的，聊起技术就刷屏了，导致我微信还被鹅厂 AI 判定骚扰 /恶意营销了。v 站、github 、邮件交流吧:joy:

@kksco thanks!

回帖里头贴代码的格式是真的伤

@lujjjh @xuantedev

go func() {
for {
func() {
timer := time.NewTimer(time.Second * 2)
defer timer.Stop()

select {
case b := <-c:
if !b {
fmt.Println(time.Now(), "work...")
}
case <-timer.C: // BBB: normal receive from channel timeout event
fmt.Println(time.Now(), "timeout")
}
}()
}
}()

简洁点就这么写，每次一个新的局部变量 Timer 结构体没压力，非要复用那么写法的可读性太差了，对维护者不友好，而且习惯了不好的写法，哪天一不小心就写出问题了

@lesismal @tim0991 #17 只要你生产速度大于协程池消费速度，一样能充分利用这些数量的协程并发。最简单的实现，一个带容量的 chan，生产者往 chan 里写，多个协程去读，当前协程都忙、就被 chan 缓冲了、发送数量大于协程数量和 chan size 生产者就阻塞，这些细节看你怎么设计，姿势太多了，我这个库里就有好几种定制的，以前有些特殊的 hash 和时序需要所以没用其他三方的：
https://github.com/lesismal/nbio/tree/master/taskpool

其他第三方的也很多

@tim0991 协程池本身就应该自带控制协程数量的属性，否则协程池还不如直接 go 。你看我上面写的也是 pool.Go

虽然自己用不上，但是很喜欢这感觉，已 star 。

@tim0991 你只要是整体的别落下 add done，每个 Go 是一个，不管 Go 的 func 里有没有失败跳过，只要 defer done 了就能确保 wg.wait 正常结束，所以，好像不应该有这个困扰

攒币不容易，上次没币了才发现，原来发帖、回复这么费币，得每天签到才行了

@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

难道不是

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

吗？

言之有理，但不是每只鸟来到这个世界都是为了枪子儿的

越年轻的一代，越在朝着更简洁的沟通方式上发展，我自己年纪大了，不去建议方式了，未来是他们的，顺其自然吧