注：本文只作了解，不建议作为面试题考察。 武林秘籍救不了段错误 包教包会包分配在各种流传甚广的 C 语言葵花宝典里，一般都有这么一条神秘的规则，不能返回局部变量： int * func(void) { int num = 1234; /* ... */ return # } duang!当函数返回后，函数的栈帧(stack frame)即被销毁，引用了被销毁位置的内存轻则数据错乱，重则 segmentation fault。 经过了八十一难，终于成为了 C 语言绝世高手，还是逃不过复杂的堆上对象引用关系导致的 dangling

Uber 最近发了一篇文章，主要讲的是在核心服务上动态调整 GOGC 来降低 GC 的 mark 阶段 CPU 占用。基本可以做到有效果，低风险，可扩展，半自动化。 Uber 当前的服务规模大概是几千微服务，基于云上的调度基础设施来进行部署。大部分服务是 GO 写的，这篇文章的作者是做 Maps Production Engineering，这个组之前帮一些 Java 系统调整过 GC 参数(这应该就是他们帮 Go 做优化想的也是怎么调整参数的出发点吧)

在任何语言的并发编程场景中，都有 race 问题，现代语言为了解决 race 问题有两种思路，一种是像 rust 那样的通过所有权+Sync/Send 限制用户尽量无法写出带 race 的代码；一种是像 Go 这样，通过 race detector 在测试期间检查数据竞争问题。 Go 的 race detector 设计决定了其无法在线上环境开启，而很多公司的项目上线前其实是没有 race test 的环节的，这就导致了一些 Gopher

之前在做性能优化分享的时候，经常会说接口延迟大幅上升时，应该先去看看 pprof 里的 goroutine 页面，看看 goroutine 是不是阻塞在什么地方了(比如锁)，如果确实是这样，那就去解决这个阻塞问题，可以大幅度优化接口的延迟。 如果我们只是做工程，知道上面这个简单的结论就可以了，最近在一个中年人技术群里，一位前同事问了这么个问题，《Systems Performance》这本书里有一个 USE 方法论，其中提到了一个 Saturation (饱和度)的概念，这个和 Utilization 有啥区别？实际工作中有把 Saturation 监控起来的么？

几个月前听过一个老同事说早期 lyft 来国内交流的时候，展示过他们强大的线下开发环境，所有的前后端服务都可以在同一台电脑上启动，颇为羡慕，正好最近陶师傅分享了 lyft 的线下环境方案 [https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-2-optimizing-for-fast-local-development-9f27a98b47ee] ，感觉参考价值挺大的。 先来定义一下问题：现在微服务架构在国内互联网公司已经普及了，互联网公司的主流程服务比较复杂，尽管已经尽最大努力进行解耦，改造过后还是会依赖几十至上百的外部服务 。这样导致的最大的问题是，业务研发在线下测试主流程服务极其困难。 如果你恰好在这样的环境工作，想一想，你在修改了主流程的代码之后，是不是没有办法在本地完成测试？是不是必须得把你的开发分支部署到远端的某个环境去？或者是不是必须部署到有 QA 维护的 Staging 环境才能开发 debug？