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

```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()
....
})

吗？

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

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

这根本就不算事：

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

并发的边界问题，应该由业务层来保证，是保证指令范围的原子性还是保证过程范围的原子性，要区分清楚

去 IOE，建议放弃 oracle 呢。

如果你们项目可用直接用 websocket 的话，如果用俺的 arpc，连 api 都可以省了：
https://github.com/lesismal/arpc/tree/master/examples/webchat

https://github.com/lesismal/arpc/blob/master/examples/protocols/websocket/jsclient/hello.html#L27
https://github.com/lesismal/arpc/blob/master/examples/webchat/chat.html#L80

大而全的微服务框架不适合中小团队直接拿来用，而大团队自家定制、不太需要用别人的

单就 RPC：
https://colobu.com/2021/08/01/benchmark-of-rpc-frameworks/
帖子中的性能数据可能不准确，最好自己跑那个代码实测下，易用性和各方面优劣可用自行对比

R9000K 　感觉不错

程序员这行，三十岁，累点的公司，鸡儿都立不起来了