@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 时打回的。

@wysnxzm 楼主是长期都没搞好，而不是一次搞好了就给你什么奖金～

@sriram 问也没用，因为不懂所以分辨不出来答案的正确性、深度、广度。

@madantech 这是都做了些什么？

别懒的申诉，你可以尝试自述一下，如果你申诉，理由是否站的住脚，在这里“委屈”“牢骚”无非是想得到认同与共鸣，真实情况你自己是应该清楚的。