介绍 GMP 的文章有很多了，大家应该也粗浅的知道什么G（goroutine）M（Machine）P（Processsor）。相较于 Java 这样的编程语言，我们经常听到一个线程池的概念。线程池就是提前创建若干个线程，如果有任务需要处理，线程池里的线程就会处理任务，处理完之后线程并不会被销毁，而是等待下一个任务。由于创建和销毁线程都是消耗系统资源的，所以当你想要频繁的创建和销毁线程的时候就可以考虑使用线程池来提升系统的性能。

所有的编程语言都有内存的管理办法，这里面分两大类；一类是编程语言提供了手动管理内存的方式，开发者必须自行对内存进行申请和释放，虽然手动管理相对精准，但是编程麻烦且稍有不慎会造成内存泄露和指针乱踩的后果。另一类是由编程语言提供了垃圾收集机制，开发者不需要手动管理内存，这为开发者提供了很大的便利。

但是，垃圾回收的工作机制并不是完美的。

前言: Go 1.18 版本正式推出了，而这个版本最大的亮点则是正式支持泛型。

今天又在网上看到了一个以前不知道的概念，内存对齐？从名字就可以看出来，这是一个偏性能优化类的概念。

在 HTTP 中传输数据有一个 chunked 的方式, 又称“分块传输”。在响应报文里用头字段Transfer-Encoding: chunked 来表示。意思是报文里的 body 部分不是一次性发过来的，而是分成了许多的块（chunk）逐个发送。而 HTTP2.0 协议作为 HTTP协议的升级，自然是对chunked模式做支持？不然！

HTTP2 是没有 chunked 的！

在 HTTP/1.x 时代，支持Body压缩，Header不支持压缩。而现在一个网页可能有几十到上百个请求，一个请求Header至少 500Byte 以上。而这些页面的请求Header大多都是一些重复的字符如UA、Cookie，会消耗不必要的带宽，增加延迟。

在HTTP/2.0中，引入了Header Compression（rfc7541），头部压缩技术使用了HPACK，有效的压缩了Header。