<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
    <channel>
      <title>Emotion&#039;s blog</title>
      <link>https://emotion.github.io</link>
      <description>最近的10条笔记 on Emotion&#039;s blog</description>
      <generator>Quartz -- quartz.jzhao.xyz</generator>
      <item>
    <title>Emotion&#039;s blog</title>
    <link>https://emotion.github.io/</link>
    <guid>https://emotion.github.io/</guid>
    <description><![CDATA[  身是菩提树，心如明镜台； 时时勤拂拭，勿使惹尘埃。 这里是 Emotion 的技术笔记，记录后端开发、存储引擎、网络协议、工具折腾等一路走来的思考。 最新文章 LevelDB 学习笔记 — 2025-03-15 what synchronized do for stale data? — 2016-05-26 更多文章正在陆续整理发布中，也可以通过左侧的目录树浏览所有公开内容。. ]]></description>
    <pubDate>Tue, 28 Apr 2026 13:54:01 GMT</pubDate>
  </item><item>
    <title>LevelDB 学习笔记</title>
    <link>https://emotion.github.io/LevelDB%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0</link>
    <guid>https://emotion.github.io/LevelDB%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0</guid>
    <description><![CDATA[ 整体理解 LevelDB 是一个基于 LSM Tree（Log-Structured Merge Tree）的嵌入式 KV 存储引擎。 它的核心思路是： 写入尽量先变成顺序写； 数据先写到内存结构，再异步落盘成有序文件； 后台通过 compaction 把多个有序文件逐步合并； 用读放大、写放大、空间放大之间的权衡，换取整体性能。 传统 B+Tree 更偏向原地更新，而 LSM Tree 更偏向追加写入。LevelDB 的写入路径基本是： WriteBatch -&gt; WAL / log file -&gt; mutable memtable -&gt; immutable memtabl... ]]></description>
    <pubDate>Sat, 15 Mar 2025 00:00:00 GMT</pubDate>
  </item><item>
    <title>what synchronized do for stale data?</title>
    <link>https://emotion.github.io/what-synchronized-do-for-stale-data</link>
    <guid>https://emotion.github.io/what-synchronized-do-for-stale-data</guid>
    <description><![CDATA[ 问题 synchronized 为什么能解决 stale data？ 标准说法是： 对同一个锁来说，一个线程释放锁之前的修改，对之后拿到同一把锁的线程可见。 这句话是对的，但是有点抽象。 我更想用一个接近硬件的方式理解它：为什么线程 A 原来可能读到旧数据，加了 synchronized 之后就不能继续读旧数据？ 一个简单模型 假设有两个线程： Thread A running on CPU A, with Cache A Thread B running on CPU B, with Cache B 还有一个共享变量： int y = 0; 可能发生这样的事情： Thread A 读过 y，... ]]></description>
    <pubDate>Thu, 26 May 2016 00:00:00 GMT</pubDate>
  </item>
    </channel>
  </rss>