@CloveAndCurrant 是这样哈，技术选型呢，可以是 LD 或者更高级的人来定，贴合自己业务场景的特点，潜在的瓶颈，规划技术架构以及技术选型来解决业务问题。团队的其他人呢，也就跟着用；所以不需要参与选型，也自然不需要了解为什么。

楼上就有人也用到 fasthttp ，他很清楚自己业务中遇到了什么问题，要怎么解决带来什么性能提升与价值。

所以，不知道不丢人，可以继续用，对不；
又不是来吵架来的，伤肝～～～

@CloveAndCurrant

一个技术贴下面， [事实] 也没有， [观点] 也没有，blabla 一堆，跟🤡一样呢。

@CloveAndCurrant 你的数据于我又什么意义？ fasthttp 的应用场景以及性能提升官网写的都很清楚； so ，你到底知不知道你们的场景为什么如此选型以及带来的性能优势如何哟；不知道就算了，不至于纠缠与嘲讽，伤肝哈。

@bronyakaka 看清了，降低并发性这部分：

我认为"在 IO 密集型业务中，哪怕存在 G 阻塞，M 挂起的行为时，Goroutine 的性能也是优秀的比线程并发强，所以它与自己比较，会降低并发行，但是这点对于其他线程并发场景，并不重要，本身就很高。" 也就不算缺点。

@CloveAndCurrant 哈哈哈哈，笑死了。 看来你是不懂的。

@CloveAndCurrant

技术选型以及性能对于基础服务的提升优势数据都没有，丢一个业务场景，可笑的家伙。

@bronyakaka
1 、goroutine 初始栈 2KB （会动态增长的，并不是说一定省内存了），而操作系统线程的栈通常 1MB
线程大小通常可以设置，但是也远比 2KB 要大;

缺点也有：
1 、没法控制怎么分配到 cpu 核上，开几个协程可能都挂一个线程上，，利用不了多核资源
GMP 模型的 M 就是利用了 Cpu 的资源，至于什么时候系统会额外的创造 M ，可以进一步了解 GMP 原理；你这第一个缺点不成立

3 、协程一旦执行阻塞系统调用，会把整个线程阻塞，导致该线程无法执行其他 goroutines ，降低并发效率
两个问题：
「 1 」，请问哪一个语言 （串行之行时，一旦阻塞了当前线程，当前线程后续还能之行动作）
「 2 」，当某个 G 被挂起，它仅会阻塞当前 G ，P 且会脱离 M ，自行寻找其他 M ，如果 M 此时不足且需要创建的话，会临时创建“M”，这恰好是优点

4 、协程不适合 CPU 密集型任务，因为没什么 io ，上下文切换反而增加了开销，，调度器也有损耗，不如用多线程直接绑定到核心上

你可以反问他一句：用户态和内核态的区别，话题终结。

@CloveAndCurrant 请介绍一下你们用 net/http 与 fasthttp 带来的性能提升指标，技术选型原因，优势在哪里，而不是你用来干嘛～～

@CloveAndCurrant 你什么场景能用到 fasthttp 的性能部分，说不出来可以开除的哦。

切换到 vscode 不用每年都去买或者折腾 license 了。

最后落地一坨不能用的 KPI 产物，浪费了人力物力财力精力现金流

@FunkYou2022 [前端，年前鹅厂毕业，] 哈哈哈哈，看错了， [前端，年前] ，看差了

前年鹅厂毕业，这两年有在做什么吗？没有一直待业吧？

这 4 个外包的面试官或许也不会得到什么正确的判断，4 个人面试一个就离谱

男模

@Hopetree 没有可能

看了这么一大堆文字，觉得，还是直接打开 host 文件修改比较快～～～～

生产者消费者再业务开发中是非常常见的场景，考察代码能力挺好的，只是题目中有一个点会让人很奇怪，waitgroup 通常用于多个 goroutine 并发执行且等待所有 goroutine 返回结果使用。比如同时请求 HTTP 、GRPC 等请求下由多个业务接口。

[两个 goroutine 用 channel 通信]

channel 原则由生产者来控制关闭。消费者直接消费，通常 v,ok:=chan 来做个逻辑判断是否关闭。
channel 另一个特点是对于已关闭的 channel 进行读时会默认返回 0 ，由第二个返回变量来判断是否关闭。所以通常消费者无需关心做额外的业务处理。

此题如果等待两个 goroutine 都结束，输出预期结果，务必需要一定的等待时间，原因在于生产者如果关闭了 channel ，则 channel 不会再有阻塞的能力。
例如：
c := make(chan int, 5)
go func{xxxxxx; close(c) }
go func(xxxxxx;}
<-c （此处不会进行任何阻塞，所以启动程序即服务进行运行结束。）

waitgroup 可以，sleep 可以，context.WithTimeout 也可以。只是这三个用在这个场景中，在真实的业务里会很奇怪。一般业务也很难遇见这样的场景吧。

楼主想根据一个场景设计题同时考察 channel 、waitgroup 或 context.Withtimeout 用法之外。还是要贴合一下实际场景好一些。

比如特性特点，使用场景能很熟悉即可。是不是要用 sleep 、context.Withtimeout 、waitgroup 并不是那么重要。原因在业务代码中，如果这样出现这样的代码逻辑，是在 codreview 时打回的。