初级会员
  • 第 22836 位会员
  • saberlong
  • 2018-09-14 13:09:18
  • Offline
  • 1 66 53

最近发布的文章

    暂无

最近分享的资源

    暂无

最近发布的项目

    暂无

最近的评论

  • 评论了主题 关于go协程池的疑问
    #9 @fichtner 使用GODEBUG进行分析。 比如`GODEBUG="schedtrace=1000" go test` `GODEBUG="scheddetail=1,schedtrace=1000" go test` 你会发现使用sleep时,调度压力其实很低的。每个P每次采样时,调度的协程数比较少。sleep期间不需要p去分配时间片。而调用testFunc时,一直在用cpu计算。所以P对协程的调度压力很大。超过一定量后协程,协程的调度损耗就体现出来了。这时候用线程池,限制数量,反而降低了调度损耗。
  • 评论了主题 关于go协程池的疑问
    #7 @fichtner 我不知道sleep改成递归是怎样一种改法。 凭空猜测,单从递归出发,递归层数多的话,会导致栈扩展。栈扩展会开辟新的空间,将旧有的栈复制过去,然后将新值压栈。
  • 评论了主题 关于go协程池的疑问
    这个问题其实就是有了异步抢占后才优化的,与表面的waitgroup无关。具体看这篇 https://studygolang.com/topics/11155
  • 评论了主题 关于go协程池的疑问
    协程池一方面是为了控制资源占用,另一方面在特定情况下提高效率,这种提高主要体现在复用。比如避免新开的协程经常发生栈扩展等。因为创建协程相比创建线程代价低太多,所以相比线程池,在这一方面不见得有提升。在硬件条件充足时,新建协程速度更快很正常。使用协程池,工作协程数量少,反而处理慢。 但看文章内容,可变因素多不好判定。建议协程池通过压测测试最合适的工作协程数量,以及最高内存占用。再做统一资源限制后(比如限制内存使用),测试不使用协程的情况。
  • 不知道你又没有注意到过,访问很多网站时,会自动去掉最后的/。</br> 而golang自带的是简单的map实现的路由,无法支持。</br> 框架是用前缀树之类的实现,所以支持了。</br> 不过我是不太喜欢这种自动重定向的功能的, 所以常常会显示设置一个handler</br>