"什么是虚拟内存 虚拟内存是计算机系统内存管理的一种技术。它使得应用程序认为它拥有连续的可用的内存（一个连续完整的地址空间），而实际上，它通常是被分隔成多个物理内存碎片，还有部分暂时存储在外部磁盘存储器上，在需要时进行数据交换。目前，大多数操作系统都使用了虚拟内存，如Windows家族的“虚拟内存”；Linux的“交换空间”等。\n为什么需要虚拟内存 我们知道程序执行指令的时候，程序计数器是顺序地一条一条指令执行下去，这一条条指令就需要连续地存储在一起，所以就需要这块内存是连续的。物理内存是有限的，如果多个程序同时运行的话，访问同一个物理地址的话，就有可能内存地址冲突，怎么办呢？\n这时就需要虚拟内存发挥的作用了，程序里有指令和各种内存地址，系统从物理内存申请一段地址，与这个程序指令里用到的内存地址建立映射关系，这样实际程序指令执行的时候，会通过虚拟内存地址，找到对应的物理内存地址执行。对于任何一个程序来说，它看到的都是同样的内存地址。我们只需要维护一个虚拟内存到物理内存的映射表即可。\n这种从物理内存申请一段地址建立映射的方法，我们称其为内存分段。\n看似解决了上面的问题，但这里又引起了新的问 …"

"参考阅读 https://mp.weixin.qq.com/s/ashgWyb-w4fT47xX60yNFA"

"示例 我们先看一下源代码\npackage main import \u0026#34;fmt\u0026#34; func f(n int) (r int) { defer func() { r += n recover() }() var fc func() defer fc() fc = func() { r += 2 } return n + 1 } func main() { fmt.Println(f(3)) } 大家感觉着打印的值是多少呢？5、9还是7？执行完以后发现是7。好像与多数理解的有些出入，为什么是7，而不是9呢。下面我们来分析一下。\n问题分析 对于defer执行的顺序是FIFO这一点都很清楚，我们只需要看搞懂f()函数的执行顺序就行了。\n执行顺序为：\n注册第1个defer 函数, 这里为匿名函数，函数体为 “func() { r += n recover() }()”，内部对应一个函数指针。这里延时函数所有相关的操作一步完成。 注册第2个defer函数，函数名为fc()，无函数体, 函数指针为nil（也有可能指针不会空，但指针指向的内容非函数体类型）。由于只是注册操作还未执行，所以并 …"

"剖析Redis常用数据类型对应的数据结构 https://time.geekbang.org/column/article/79159\nredis中的COW(Copy-On-Write) https://www.jianshu.com/p/b2fb2ee5e3a0\nredis常用有哪些数据类型及每种数据类型的使用场景有哪些 https://www.cnblogs.com/tqlin/p/10478459.html\n如果存储一个JSON数据时，选择hash还是string 存储数据？ https://segmentfault.com/a/1190000019552836\nredis与memcache的区别 https://www.cnblogs.com/JavaBlackHole/p/7726195.html https://blog.csdn.net/qq_34126805/article/details/81748107\nredis支持多CPU吗？如何发挥多cpu？ https://blog.csdn.net/tanga842428/article/details/52641484 …"

"golang中的select语句格式如下\nselect { case \u0026lt;-ch1: // 如果从 ch1 信道成功接收数据，则执行该分支代码 case ch2 \u0026lt;- 1: // 如果成功向 ch2 信道成功发送数据，则执行该分支代码 default: // 如果上面都没有成功，则进入 default 分支处理流程 } 可以看到select的语法结构有点类似于switch，但又有些不同。\nselect里的case后面并不带判断条件，而是一个信道的操作，不同于switch里的case，对于从其它语言转过来的开发者来说有些需要特别注意的地方。\ngolang 的 select 就是监听 IO 操作，当 IO 操作发生时，触发相应的动作每个case语句里必须是一个IO操作，确切的说，应该是一个面向channel的IO操作。\n注：Go 语言的 select 语句借鉴自 Unix 的 select() 函数，在 Unix 中，可以通过调用 select() 函数来监控一系列的文件句柄，一旦其中一个文件句柄发生了 IO 动作，该 select() 调用就会被返回（C 语言中就是这么做的）， …"

"GODEBUG, 输出结果以gc 开头的表示进行了gc垃圾回收操作，后面的数字表示gc 的次数 pprof"

"参考文章 Golang 的 协程调度机制 与 GOMAXPROCS 性能调优 深入Golang之sync.Pool详解 golang sync.Pool 分析 [译] Go: 理解 Sync.Pool 的设计 视频 sync.pool对象缓存 知识点 Pool只是一个缓存，一个缓存，一个缓存。由于生命周期受GC的影响，一定不要用于数据库连接池这类的应用场景，它只是一个缓存。 golang1.13版本对 Pool 进行了优化，结构体添加了两个字段 victim 和 victimSize。 适应于通过复用，降低复杂对象的创建和GC代价的场景 因为init()的时候会注册一个PoolCleanup函数，他会在gc时清除掉sync.Pool中的所有的缓存的对象。所以每个sync.Pool的生命周期为两次GC中间时段才有效，可以手动进行gc操作 runtime.GC() 由于要保证协程安全，所以会有锁的开销 每个Pool都有一个私有池（协程安全）和共享池(协程不安全)，其中私有池只有存放一个值。 每次Get()时会先从当前P的私有池private中获取（ 类似MPG模型中的G） 如果获取失败，再 …"

"最近在用go重构iot中的一个服务时，发现库 [email protected] 在初始化消费客户端实现时，实现的极其优雅，代码见 https://github.com/apache/rocketmq-client-go/blob/v2.0.0-rc1/examples/consumer/simple/main.go#L32\nc, _ := rocketmq.NewPushConsumer( consumer.WithGroupName(\u0026#34;testGroup\u0026#34;), consumer.WithNameServer([]string{\u0026#34;127.0.0.1:9876\u0026#34;}), ) err := c.Subscribe(\u0026#34;test\u0026#34;, consumer.MessageSelector{}, func(ctx context.Context, msgs ...*primitive.MessageExt) (consumer.ConsumeResult, error) { for i := range msgs { …"

"一、InnoDB Buffer Pool简介 Buffer Pool是InnoDB引擎内存中的一块区域，主要用来缓存表和索引数据使用。我们知道从内存读取数据要比磁盘读取效率要高的多，这也正是buffer pool发挥的主要作用。一般配置值都比较大，在专用数据库服务器上，大小为物理内存的80%左右。\n二、Buffer Pool LRU 算法 Buffer Pool 链表使用优化改良后LRU(最近最少使用)算法进行管理。\n整个LRU链表可分为两个子链表，一个是New Sublist，也称为Young列表或新生代，另一个是Old Sublist ，称为Old 列表或老生代。每个子链表都有一个Head和Tail，中间部分是存储Page数据的地方。\n当新的Page放入 Buffer Pool 缓存池的时候，会交其Page插入就是两个子链表的交界处，称为midpoint，同时就会有旧的Page被淘汰，整个操作过程都需要对链接进行维护。\nYoung 链表区存放的数据是经常访问的数据； Old 链表区存放是即将被淘汰的数据；\n一个新数据先被插入到midpoint 位置，根据LRU算法访问频率高 …"

"docker在开发和运维中使用的场景越来越多，作为开发人员非常有必要了解一些docker的基本知识，而离我们工作中最近的也就是对应用的docker部署编排了，小到一个dockerfile, docker-compse文件的编写，大到k8s的管理。这里我们以 golang应用为例讲解一些Dockerfile的基本用法，在ci/cd中经常用到这些知识。\n前提 项目清单：\ndrwxr-xr-x 9 sxf staff 288 12 31 16:13 . drwx------@ 17 sxf staff 544 12 31 14:59 .. -rw-r--r-- 1 sxf staff 14 12 31 16:09 .dockerignore drwxr-xr-x 14 sxf staff 448 12 31 16:21 .git -rw-r--r-- 1 sxf staff 467 12 31 16:08 Dockerfile -rw-r--r-- 1 sxf staff 11 12 31 15:01 README.md -rw-r--r-- 1 sxf staff 84 12 31 …"