最近遇到一个Go内存不释放的问题，记录一下测试和调研的情况。我到不把它归为Go内存泄漏的问题，因为它和一般的内存泄漏的方式不同。
Hi, 使用多年的go pprof检查内存泄漏的方法居然是错的?!
最近在做一个 Redis 的 Proxy 的项目，其中利用Redis 6.0 新加的 tracking 功能实现客户端缓存的功能，可以为某些特定的redis使用场景提高吞吐和延迟。
当然，cache的实现也是有代价的。首先，cache的大小不能无限制的大，否则总有一点会把内存撑爆的；其次，cache的淘汰算法有多种方式，LRU、LFU等等，具体可以参考Cache replacement policies，不同的场景下各种淘汰算法的效果是不一样的；第三，对于大并发情况实现cache是有代价的，因为并发情况下对cache的访问需要加锁，而加锁就意味着有性能的损失。
我在实现这个cache的过程中稍微偷了一下懒, 想尽量的减少锁的scope,结果导致内存泄漏的问题。本来cache占用的最大内存我设置为10GB, 结果过了个周末发现程序已经占用了80GB的内存了。
当然本文不是要介绍这个项目的内存泄漏原因，而是介绍一下Go pprof工具查找内存泄漏的一个不太常用的方法。
读写 Redis RESP3 协议以及Redis 6.0客户端缓存
在四月份的一篇翻译的文章中，我介绍了读写Redis RESP version 2的协议的Go 语言的实现，你可以使用它采用底层的方式读写5.0以及以下版本的Redis。Redis 6.0还在开发之中年底或者明年初就要发布了。Redis 6.0支持多线程I/O，还有客户端缓存。
客户端缓存是未来Redis最重要的特性。如果我们需要快速存储和快速缓存，那么我们就需要在客户端存储数据的子集。这是为了提供小延迟、大规模数据的想法的自然延伸。很多公司都采用了在客户端缓存数据以避免每次都请求redis，但是本地缓存和redis服务器数据之间有延迟，很难保证数据的一致性。Ben Malec在Redis Conf 2018上做了一个关于客户端缓存的演讲，给了Salvatore Sanfilippo以灵感，Salvatore Sanfilippo决定在Redis 6.0中支持客户端缓存的功能。但是为了支持这个功能，使用当前的redis协议很难实现，所以他设计了下一代的Redis协议: RESP3。
Go并发设计模式之 Half-Sync/Half-Async
半同步/半异步（half-sync/half-async）的模式集成了同步IO模式和异步IO模型，既简化了并发系统的开发，又兼顾了效率。在这个并发设计模式的实现中，高级的任务使用同步IO模型，使开发者可以无太多的心智负担在并发编程中，底层的任务使用异步IO模型，这就提高了并发的效率。这个设计模式广泛的应用在操作系统的实现中，如UNIX、Mach，Windows等。
Go并发设计模式之 Active Object
设计模式曾经很火，尤其是1995年的时候Erich Gamma, Richard Helm, Ralph Johnson 和 John Vlissides (GoF)推出的《设计模式》一书，可谓经典。这本书总结了面向对象设计中最有价值的经验，并且用简洁可复用的形式表达出来。书中分类描述了23种经典实用的设计模式，这些实际模式依然在现在的实际开发中被广泛实用。
当然，这23种设计模式并不能涵盖所有的模式场景，同时，书中也没有对其它领域的一些设计模式进行归纳总结和介绍，比如并发场景，数据库设计、前端设计、架构模式等等，这个问题GoF中也已经进行了说明。二十几年过去了，期间也陆陆续续的出了一些介绍模式的书，有些是对GoF的23中设计模式的具体语言的介绍、阐述等等，也有一些设计模式的书，介绍了企业开发中的其它领域的设计模式，有一些书还是非常值得一读的。
我会写一系列介绍并发设计模式的文章，主要介绍实用Go语言去实现这些并发设计模式，但是我不想遵循介绍设计模式的模版，而是结合很多流行的Go的项目和库，从实践的角度去介绍这些并发设计模式。这种介绍方式一是可以让读者更容易的去理解设计模式，而不是拿一些老掉牙、根本不会使用的例子来介绍，二来可以坚定读者的信心，因为这些并发设计模式已经在流行的项目中使用了，得到了实际的检验。
作为开篇一章，我介绍的是 Active Object设计模式，为什么拿它作为第一篇呢，因为它的首字母是A,最大。
[译]利用 gopackage 进行包的捕获、注入和分析
原文: Packet Capture, Injection, and Analysis with Gopacket by John Leon。
最近准备使用 gopackage 写个工具，搜索了相关的资料，这篇文章是值的推荐的一篇介绍 gopackage的文档，所以动手翻译了一下。
gopacket包为用C编写的libpcap提供了一个go包装器(译者按: 不仅如此，现在gopackage有多种捕获包的binding方式，比如PF_RING，AF_PACKET等)，但它不仅仅是一个简单的包装器。它提供了额外的功能，并利用了Go之类的接口，这使得它非常强大。
作者在写这篇文章的时候，在Denver GopherCon 2016 大会上分享了相关的技术，有兴趣的同学可以观看: GopherCon 2016: John Leon - Packet Capture, Analysis, and Injection with Go
[译]配置 sql.DB 获得更好的性能
原文2020年4月9日已更新，请阅读最新译文
原文: Configuring sql.DB for Better Performance
网上有很多教程介绍sql.DB, 以及如何使用它来执行SQL数据库查询和语句, 但是大部分都没有介绍SetMaxOpenConns（）、SetMaxIdleConns（）和SetConnmaxLifetime（）方法。事实上你可以使用这些方法来配置sql.DB的行为并改善其性能。
在这篇文章中，我想准确地解释这些设置的作用，并演示它们可能产生的（正面和负面）影响。
[译]Go性能分析工具工具和手段
翻译自 Basics of benchmarking, profiling and tracing with Go，作者对Go性能分析的工具和手段做了一个很好的总结。
这篇文档提供了Go提供的测量性能和收集运行时信息的工具的概览。它不是一个关于基准测试、性能分析和跟踪的详细教程。
所以这篇文档也可以看成是一篇备忘录。
在大多数情况下，您可以通过运行提供的示例源代码自行尝试。作为一种现场演示或研讨会，很容易使用这些工具进行试验和体验。
主要内容包括：
- Benchmarking(基准测试)：专注于一段特定的代码, 允许测量时间 和/或 内存信息。
- Profiling(分析)：在程序执行期间(或测试的时候)通过聚合采样收集的数据。分析是没有时间线的(和tracing不一样)。
- Tracing(跟踪)：通过程序执行期间(或测试的时候)收集发生的事件数据。跟踪是有时间线的。
基准测试：专注于一段特定的代码，允许测量时间和/或内存信息。
分析：在程序（或测试）执行期间通过采样收集的聚合数据。分析没有时间线。
跟踪：通过程序（或测试）执行期间发生的事件收集的数据。跟踪有时间线。
分析和跟踪技术可以应用于基准测试。
Gopher 2019 Go并发编程的分享
昨天参加了 Gopher China 2019 大会，分享了《Go并发编程实践》的主题，在这一篇博客中总结一下。
从春节前开始我就有意识的收集和整理Go并发编程的相关知识，以前也有相关的博文进行过分享，本来是想以电子书的方式进行分享，正好Asta Xie邀请在Gopher China 2019上做一个分享，就毫不犹豫的答应了。
谈起Go并发编程的分享，每年各地的Go相关的大会都会有，基本上都会针对某一个专题进行介绍，或者针对Go并发编程的哲学进行分享。所以我给自己定了两个方向: 一个是结合业务讲一些Go并发编程在企业实际开发中的实践，另外一个是对Go并发编程做一个全面的总结。
我选择了后一个，也是最难的一个。一是内容非常多，而且不结合业务，只讨论编程语言相关的知识，因为涉及到细节，多少会有些枯燥，尤其是针对主要关注于业务同学，但是对于热心于Go编程语言的开发者来说，能有人对Go并发进行一个深入而全面的总结，对于自己回顾和整理Go并发编程的技能，多多少少会有所帮助的，所以我愿意进行一次尝试。
最初开始整理了很多的知识点，内容太多了，我忍痛删去了Go并发编程设计模式一节，第一版120多页的ppt发给Asta之后，Asta感觉还是太多，又忍痛删去了分布式并发原语这一节，最后整理了81页的PPT。我是实在不想删减了，再删减，就变成了《Go标准sync库在实践中的几个坑》，就偏离了我最初的分享的目的：全面总结Go并发编程知识，而退化成第一个选择：找一个直接点结合业务进行分享。编写PPT原则就是每一页都是干货。
80页的PPT想在45分钟内顺利的讲完，并且不讲业务只讲Go语言的特性，非常的困难，我预想到会拖堂，实际也完美做到了，所以后面的介绍比较的匆忙了，这些都在预想的流程之内，也是希望大家拿到ppt之后有个回顾，将来遇到并发的问题至少能在ppt找到答案。当然如果你不想看冗长的ppt和代码的话，这篇文章或许能对你的理解能够更顺畅一些，也希望对未能参加会议的朋友能有所帮助。
