马上就二月二了，理发店就要忙活起来了，托尼、凯文、艾伦等老师的理发剪磨刀霍霍，把椅子擦亮，准备各位顾客的到来。
Sleeping barber problem是一个经典的goroutine交互和并发控制的问题，可以很好的用来演示多写多读的并发问题(multiple writers multiple readers)。
pyroscope: 一个简单易用的持续剖析平台
开发人员常常需要跟踪生产环境中的应用程序的性能瓶颈，并试图找出造成瓶颈的根本原因。要做到这一点，他们通常会通过日志来收集这些信息。不幸的是，这种方法可能会很耗时，而且无法提供有关潜在问题的足够详细的信息。
一种现代且更先进的方法是应用和使用profiling技术和工具，突出显示最慢的应用程序代码和消耗大部分资源（如CPU和内存）的方法。持续分析(Continuous profiling)是在生产环境中持续 收集应用程序性能数据，并将这些数据提供给开发人员进行深入分析的过程。
通过，我们通过采集程序的指标，生成一个概要文件(Profile)进行单次的分析。Go语言提供了pprof工具，可以很方便的生成profile文件。你可以通过程序调用runtime/pprof生成CPU、Heap等概要文件，也可以使用net/http/pprof集成到web应用程序中，通过go tool pprof工具在命令行或者web页面中进行分析。
有时候，我们不能及时的进行pprof分析，故障可能消失了或者程序已经crash了。另外我们可能需要不同时段的profile进行对比，进行比较才能发现问题，比如内存泄露的问题。这个时候持续分析(continuous profiling)就很重要了。很多云服务厂商都提供持续分析的功能，比如Go Continuous Profiler | Datadog、Cloud Profiler | Google Cloud、Amazon CodeGuru Profiler等。
编写可维护的Go代码
编写可维护的代码是最基本的要求。清晰度、可读性和简单性都是保持代码可维护性的各个方面。它应该使某人加入您的项目或在有人离开后维护代码的过程变得容易。可维护性的衡量指标是代码更改的容易程度以及与这些更改引起的风险性。为了有效地编写Go程序，了解Go语言的属性和地道写法，并使用与命名、程序构建、格式等相关既定约定是至关重要。
以下是一些有助于编写可维护的Go代码的良好实践。
原文: Writing maintainable Go code by Jogendra.
Go泛型编程: interface 不再是那个interface
自 Go 1.18 支持泛型后， Go interface 的意义已经彻彻底底的改变了，除了先前代表的方法集的意义外，还被用作泛型的类型约束(type constraint)的功能, interface已经不再是以前那个单纯的少年了。
[译] go fuzzing
Go fuzzing(模糊测试)是Go 1.18发布的另一个非常重要的特性，因为Go泛型已经把大家的目光都吸引过去了，导致go fuzzing这个特性有些人还不是太了解。Go官方发布了一个文档，介绍了Go Fuzzing技术。
Go Fuzzing
Go泛型不支持泛型方法，这是一个悲伤的故事
根据Go 泛型提案的描述，Go不支持泛型方法:No parameterized methods。主要原因Go泛型的处理是在编译的时候实现的，泛型方法在编译的时候，如果没有上下文的分析推断，很难判断泛型方案该如何实例化，甚至判断不了，导致目前(Go 1.18)Go实现中不支持泛型方案。
不过，泛型方法的缺失，多多少少给程序员带来一丝丝的忧伤的情绪，在一些场景之下，使用起来特别不方便。我最近看到了几个因为缺乏泛型方法导致的问题，在本文中总结一下，和大家探讨。
有一点点让人欣慰的是，Ian Lance Taylor和Ian Lance Taylor并没有把话说绝，说不定在某个版本中，泛型方法又支持了:
So while parameterized methods seem clearly useful at first glance, we would have to decide what they mean and how to implement that.
