闭包其实挺好理解的，比如你有一个函数，会返回一个回调函数，这个回调函数中会持有一些自己的局部变量
function bar() {
return function() {
int tmp = 1;
print(tmp);
}
}
callback = bar();
callback();

你当然也可以不返回回调函数，而是返回一个 class,就像下面这样：
class C {
private int tmp;

public C(int tmp) {
this.tmp = tmp;
}

public callback() {
print(tmp);
}
}

function foo() C {
c = new C(1);
return C;
}
foo().callback();

达成的效果其实是一样的，返回的闭包函数其实就等价于一个带有私有属性和一个 method 的 class 。

1. 协程解决的问题
java 实现一个支持并发的 http server,最简单的方案可能就是拿到一个连接就创建一个线程来执行，即一个多线程的 server 。这个 server 连接数高了性能就会非常差，因为线程数会很高，线程切换开销比较大。

现在有个协程，因为协程开销比较小，你仍然可以用这个简单的思路去实现，即拿到一个连接就创建一个协程来执行。go 标准库中 http server 就是这么实现的，简单粗暴。在 go 中实际是封装了 epoll(linux 平台)，由 runtime 调度协程跑在很少数量的线程上，实际上压根就不是原始的多线程方案了，应该是 epoll 方案，所以对于用户来说能以很简单的方式就能实现高性能并发，这就是协程解决的问题之一。

网易云课堂有个视频： https://study.163.com/course/introduction/1002830012.htm ，可以跟着敲一遍代码应该就懂了，再回头看各种编译原理的理论就好懂了。by the way，前端学完了感觉就那么回事，无非就是一些算法，真正的星辰大海还是后端😄。

Navicat 和微服务查询同一条 SQL 时间差这么多 可能是有慢查询导致连接池满了，请求线程都在等连接。

还是上监控吧😄

进到 swap 了？

init 函数中 accessLog = Counter{data: make(map[string]int)}这句代码不是原子的吧，换成
accessLog.Lock()
accessLog.data = make(map[string]int)
accessLog.RUnlock()

试试呢？

4 楼正解。正好前段时间我也深入研究了这个问题，并且整理成了一篇博客: https://blog.fanscore.cn/p/34/ 楼主可以参考下，或许对你有帮助😄

@xuletter2021 确实结果一样，不过关闭优化前后打印汇编结果还是有区别的，虽然关闭优化后的 go 出来的函数中还是没有 x++对应的汇编代码（不太能理解的...）。

下面是我的猜测：

在 1.14 之前协程调度是出让式而非抢占式的，如果这段代码在单核机器上运行，就有可能陷入到 for {...}的死循环中而主协程中的代码得不到调度执行，而你 for 循环中加入了 fmt.Pxxx 类的代码就能够使子协程出让执行权。

另外这段代码还有可见性问题，子协程对全局变量的修改，主协程可能是看不到的。

基于上面两个问题的考虑，编译器做出了“错误”优化，导致了你所看到的结果。

你关闭优化跑一遍看看是不是出来了？😂

7 楼回复应该是个很常见的设计，我司 redis 就分为缓存(不需要持久化，所有 key 都有过期时间)与持久化数据两种实例，楼主可以做个参考。如果麻烦的话，可以考虑该场景能否使用 bitmap 来做过滤

@yzbythesea 感谢提醒，突然意识到了

@yzbythesea CPU 操作 L3 cache 上同一个 cacheline 同一位置数据，不加 Lock 就不是原子的，这样理解吗？如果不加 Lock 也是原子的，那 CPU 没必要锁吧

@Jooooooooo lock 与寄存器无关

@ob 好像是会换了，忘记了😄

用 golang 快写完了突然发现还不如用 java 写，方便在安卓上跑😏。