<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://blog.miigon.net/</id><title>Miigon's blog</title><subtitle>Here's a little garden where I share everything I've thought and learned.</subtitle> <updated>2023-08-17T15:41:18+08:00</updated> <author> <name>Miigon</name> <uri>https://blog.miigon.net/</uri> </author><link rel="self" type="application/atom+xml" href="https://blog.miigon.net/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://blog.miigon.net/"/> <generator uri="https://jekyllrb.com/" version="4.3.2">Jekyll</generator> <rights> © 2023 Miigon </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>随笔：Golang 循环变量引用问题以及官方语义修复</title><link href="https://blog.miigon.net/posts/golang-loop-var-reference-problems-and-semantic-fix/" rel="alternate" type="text/html" title="随笔：Golang 循环变量引用问题以及官方语义修复" /><published>2023-03-15T17:05:00+08:00</published> <updated>2023-03-15T17:20:56+08:00</updated> <id>https://blog.miigon.net/posts/golang-loop-var-reference-problems-and-semantic-fix/</id> <content src="https://blog.miigon.net/posts/golang-loop-var-reference-problems-and-semantic-fix/" /> <author> <name>Miigon</name> </author> <category term="Language" /> <category term="Golang" /> <summary> 这篇文章谈一个已经在 Golang 中存在多年的，几乎每一个新手都要被坑一遍的设计：引用捕获了循环变量，且逃逸出循环迭代范围而造成的逻辑错误。 以及重点是讨论了目前对这个常见问题的解决办法的探索（静态分析存在的不足，以及2022年10月 Golang 官方提出的直接更改 for 循环变量语义，从语言设计上根本地消除这个问题的 proposal） background 这个问题是一个 Golang 从很早版本就一直存在的设计选择造成的。 简单地讲就是 for 循环中，由于 func 捕获，或者显式/隐式的取引用，对循环变量产生了引用并且这个引用逃逸出了当前循环迭代（iteration）的生命周期范围。而由于 Golang 一开始决定将将循环变量（i、k、v）的生命周期定义为整个循环，而不是每个迭代都有新一份的循环变量，导致了每一轮迭代产生的引用实际上都指向同一个值，而不是指向每一... </summary> </entry> <entry><title>[随笔]文件系统上存储哈希对象：哈希算法以及目录结构对性能的影响</title><link href="https://blog.miigon.net/posts/storing-hash-objects-on-filesystem/" rel="alternate" type="text/html" title="[随笔]文件系统上存储哈希对象：哈希算法以及目录结构对性能的影响" /><published>2022-12-30T17:16:00+08:00</published> <updated>2023-03-30T14:32:26+08:00</updated> <id>https://blog.miigon.net/posts/storing-hash-objects-on-filesystem/</id> <content src="https://blog.miigon.net/posts/storing-hash-objects-on-filesystem/" /> <author> <name>Miigon</name> </author> <category term="Misc" /> <category term="Unix" /> <summary> 从文件系统的实现原理角度讨论 /77/e1/77e1cccccc... 模式的 hash object 命名的优点以及必要/不必要性，以及算法选择。 原贴 这是我在 0xffff 论坛的回帖的备档：https://0xffff.one/d/1395-wen-jian-xi-tong-zuo-wei-huan-cun 一个常见的业务场景，需要实现一个 Key-Value Cache Storage，除了 Redis 等外，有一个方向是用设备本身的文件系统来落地。 大概操作是，用 Key 生成 Path，再基于这个 Path 去读写文件，再将结果返回给业务，这个操作通常是 Key 经过 hash 函数算出一个值 取这个值的前四位，做一个二级目录，如 77e1ba46ee3a2b2d1558d7c5d07c4c0caa46c7bf，生成一个 77/e1/77e1... </summary> </entry> <entry><title>Linux 是否有 zombie thread？从glibc和内核源码探究</title><link href="https://blog.miigon.net/posts/does-linux-has-zombie-thread/" rel="alternate" type="text/html" title="Linux 是否有 zombie thread？从glibc和内核源码探究" /><published>2022-11-23T17:47:00+08:00</published> <updated>2022-11-25T14:05:20+08:00</updated> <id>https://blog.miigon.net/posts/does-linux-has-zombie-thread/</id> <content src="https://blog.miigon.net/posts/does-linux-has-zombie-thread/" /> <author> <name>Miigon</name> </author> <category term="Linux" /> <summary> 系统编程课上遇到的一个问题：Linux下，如果一个 pthread_create 创建的线程没有被 pthread_join 回收，是否会和僵尸进程一样，产生“僵尸线程”，并一直占用一个 pid/tid？ 猜想 僵尸进程 对于进程与子进程来说，如果子进程退出了，但是父进程不对子进程进行 reap （即使用 wait/waitpid 对子进程进行回收），则子进程的 PCB（内核中的 task_struct）依然会保留，用于记录返回状态直到父进程获取，并且状态将被设置成 ZOMBIE，即产生“僵尸线程”。 #include &amp;lt;unistd.h&amp;gt; int main() { if(fork() == 0) { return 0; // child exits immediately } while(1); // parent loo... </summary> </entry> <entry><title>MySQL Prepare后语句查询性能降低 内核源码bug排查分析</title><link href="https://blog.miigon.net/posts/mysql-prepare-slower-query-bug-analyze/" rel="alternate" type="text/html" title="MySQL Prepare后语句查询性能降低 内核源码bug排查分析" /><published>2022-11-18T18:00:00+08:00</published> <updated>2022-11-25T14:22:25+08:00</updated> <id>https://blog.miigon.net/posts/mysql-prepare-slower-query-bug-analyze/</id> <content src="https://blog.miigon.net/posts/mysql-prepare-slower-query-bug-analyze/" /> <author> <name>Miigon</name> </author> <category term="Backend" /> <category term="Database" /> <category term="MySQL" /> <summary> 源自于业务上遇到的一个先将某个语句Prepare再Execute查询效率很低的问题，而将查询中的参数直接嵌入到SQL语句内并以文本形式执行，则执行反而变得很快。 测试环境：腾讯云 MySQL 服务（txsql8.0.22）、MySQL 源码编译（refs/tags/mysql-8.0.22） 问题描述 背景 MySQL 中，语句执行有两种方式，分别是 Text Protocol 和 Prepared Statement。两者主要的差别是传参方式的不同（返回包格式也不同，这里不展开）。 Text Protocol 是直接将语句中的参数嵌入到 SQL 语句中，以文本的形式整个语句直接传递到数据库。（后面称为「文本SQL模式」） Prepared Statement 则是先 COM_STMT_PREPARE 一个查询语句的模板，如 SELECT * FROM t1 WHE... </summary> </entry> <entry><title>MIT6.830 Database Systems | 数据库系统</title><link href="https://blog.miigon.net/posts/mit6830-database-systems/" rel="alternate" type="text/html" title="MIT6.830 Database Systems | 数据库系统" /><published>2022-08-24T18:24:00+08:00</published> <updated>2022-08-24T18:36:31+08:00</updated> <id>https://blog.miigon.net/posts/mit6830-database-systems/</id> <content src="https://blog.miigon.net/posts/mit6830-database-systems/" /> <author> <name>Miigon</name> </author> <category term="Course Notes" /> <category term="MIT6.830" /> <summary> MIT6.830 Database Systems (Spring 2021) 前置课程： 6.033 Computer System Design 计算机系统设计 这门课与MIT 6.814是同一门课程，两者区别在于Final Project在6.814中由Lab5以及Lab6替代。虽然这门课是研究生课程，但是在MIT里，这门课大概1/3的学生是本科生。 课程介绍 MIT6.830 Database Systems 数据库系统课程为麻省理工学院的研究生课程，主要通过来自数据库社区的阅读材料（论文），向学生介绍数据库系统的基础，重点关注基本概念，如实现关系代数和数据模型、schema 范式化、查询优化、事务等。课程不假设学生有任何先前的数据库经验。 涉及话题 与数据库系统的设计有关的话题，包括：数据模型、数据库和 schema 设计、schema... </summary> </entry> </feed>
