Java 字符编码与 Unicode 完全指南——从 BMP 到增补平面，从代码单元到字形簇
“一个 char 就是一个字符”——这个直觉在 Java 中是错误的。一个 emoji 👨👩👧👦 在 Java 中占 11 个 char，但在用户眼中只是一个字符。本文将从 Unicode 的基础概念出发，深入剖析 Java 的字符编码机制，揭示 char、码点、代码单元、字形簇之间的层次关系。 Part 1: Unicode 基础——字符集的大一统 从 ASCII 到 Unicode 的演进 编码 年份 字符数 位宽 覆盖范围 ASCII 1963 128 7 位 英文字母、数字、控制字符 ISO 8859-1 1987 256 8 位 西欧语言 GB2312 1980 6,763 汉字 双字节 简体中文 GBK 1995 21,886 汉字 双字节 简繁中文 Shift_JIS 1982 ~7,000 变长 日文 Unicode 1.0 1991 7,161 16 位（最初设想） 多语言 Unicode 16.0 2024 154,998 21 位（实际） 全球所有文字 + emoji Unicode 之前的世界是编...
MESI 协议与 Java 并发可见性——从硬件到 JMM
为什么 volatile 能保证可见性？为什么 synchronized 既保证原子性又保证可见性？答案藏在 CPU 缓存一致性协议和内存屏障中。本文将从硬件层面的 MESI 协议出发，逐步上升到 Java 内存模型（JMM），揭示并发可见性问题的完整因果链。 Part 1: CPU 缓存架构 为什么需要 CPU 缓存 现代 CPU 的运算速度远超内存访问速度，两者之间存在巨大的速度鸿沟： 操作 延迟 相对速度 CPU 寄存器访问 ~0.3 ns 1x L1 Cache 访问 ~1 ns 3x L2 Cache 访问 ~4 ns 13x L3 Cache 访问 ~12 ns 40x 主内存访问 ~100 ns 333x 如果 CPU 每次都直接访问主内存，大部分时间都在等待数据。缓存利用了时间局部性和空间局部性，将最近和附近的数据保存在更快的存储中。 多级缓存架构 12345678910111213141516171819┌──────────────────────────────────────────────────────┐│ ...
副本复制算法与架构——PacificA、Elasticsearch、Kafka、Pulsar 全面对比
本文将深入剖析 PacificA、Elasticsearch、Kafka、Pulsar 四大分布式系统的副本复制机制，揭示它们在一致性、可用性和性能之间的精妙权衡。这些系统虽然都通过副本复制来保证数据可靠性和高可用性，但在具体的实现策略上各有特色，反映了不同的设计哲学和适用场景。 引言：为什么需要副本复制 数据可靠性与高可用性 在分布式系统中，硬件故障是常态而非例外。Google 的统计数据显示，一个拥有 10,000 台服务器的数据中心，每天平均会有 2-3 台服务器发生故障。如果数据只存储在一台机器上，那么这台机器的故障就意味着数据的永久丢失。 副本复制（Replication） 是解决这个问题的核心手段：将数据复制到多台机器上，即使部分机器故障，数据仍然可用。 CAP 定理的实际影响 CAP 定理告诉我们，在网络分区（Partition）发生时，分布式系统只能在**一致性（Consistency）和可用性（Availability）**之间二选一： 选择 含义 代表系统 CP 网络分区时拒绝服务，保证一致性 ZooKeeper、etcd、HBase AP...
原码·反码·补码——从环形数轴到 CPU 减法器
CPU 只有加法器，没有减法器。为了让 A - B 直接变成 A + (-B)，人们发明了补码；原码、反码只是推导脚手架。本文将从最基础的原码出发，经过反码的过渡，最终抵达补码的本质——环形数轴上的模运算，并深入探讨补码在不同编程语言中的体现。 Part 1: 原码——人类的直觉 符号位 + 绝对值 原码是最直观的有符号整数表示方法：最高位表示符号（0 正 1 负），其余位表示绝对值。 以 8 位为例： 十进制 原码 说明 +5 0000 0101 符号位 0（正），绝对值 5 -5 1000 0101 符号位 1（负），绝对值 5 +0 0000 0000 正零 -0 1000 0000 负零 +127 0111 1111 最大正数 -127 1111 1111 最小负数 表示范围：-127 到 +127，共 255 个不同的值（因为 +0 和 -0 占了两个编码）。 原码的致命缺陷 缺陷一：双零问题 +0（0000 0000）和 -0（1000 0000）是两个不同的编码，但它们表示的是同一个数学值 0。这给硬件判断"结果是...
数据库写入的潜规则——合并树与 MPP 架构深度剖析
许多开发者在使用 ClickHouse、HBase、Elasticsearch 等现代数据系统时，都会遇到"不建议高频写入"的限制。这一限制常被归因于"列式存储"，但这是一个常见的误解。 高频写入受限的根本原因在于数据库的存储引擎架构。本文将深入剖析四大主流架构——LSM-Tree、ClickHouse MergeTree、MPP 和 B-Tree——分析它们各自的写入机制、性能权衡，以及它们"偏爱"批量写入的底层原因。 Part 1: 磁盘 I/O 基础——理解一切的前提 深入存储引擎之前，有必要先理解磁盘 I/O 的基本特性，因为所有存储引擎的设计都是围绕磁盘特性做出的权衡。 随机写 vs 顺序写 指标 HDD（机械硬盘） SSD（固态硬盘） 内存（DRAM） 随机写 IOPS ~100-200 10K-100K ~10M 顺序写吞吐 ~100-200 MB/s 500 MB/s - 3 GB/s ~10 GB/s 随机写延迟 ~10ms（寻道时间） ~100μs ~100ns 顺序写延迟...
经典面试问题的大数据解法——Spark 与 Flink 实战
“100 亿个数中找出最大的 1000 个”、“两个 10GB 的文件找出共同的 URL”——这些经典面试题的本质都是内存放不下。本文将系统性地梳理大数据场景下的 TopK、排序、去重、词频统计等经典问题，给出从单机到分布式（Spark/Flink）的完整解法。 引言：大数据问题的共同特征 为什么"内存放不下" 数据规模 内存需求 典型服务器内存 能否放入内存 1 亿个 int 400 MB 16 GB ✅ 10 亿个 int 4 GB 16 GB ✅ 100 亿个 int 40 GB 16 GB ❌ 10 亿个 URL（平均 100 字节） 100 GB 16 GB ❌ 通用解题框架 123456789101112大数据问题 │ ▼能否放入内存？ ├── 能 → 直接用内存数据结构解决 │ ▼ 不能 → 分而治之 │ ├── 1. 分区（Partition）：按哈希/范围将数据分成小块 ├── 2. 局部处理：每个小块在内存中处理 └── 3. 合并（Merge）：...
Java 集合框架完全指南
Java 集合框架完全指南 本文系统性地介绍 Java 集合框架的核心概念、实现原理和设计模式。内容涵盖集合框架体系结构、列表与队列机制、哈希表家族的扩缩容策略、缓存淘汰算法实现以及系统级扩缩容设计。通过深入分析源码实现和性能特征，帮助理解各集合类的适用场景和最佳实践。 第一章：全景导图 文章结构 mindmap root((Java集合框架完全指南)) 集合框架体系 Iterable接口 Collection体系 Map体系 Sorted接口 Navigable接口 抽象类层次 列表与队列 ArrayList扩缩容 队列六操作 PriorityQueue DelayQueue Deque体系 哈希表家族 HashMap结构 扩容机制 扰动函数 树化反树化 ConcurrentHashMap LinkedHashMap EnumSet/Ma...
缓存系统设计——从穿透到雪崩的完整攻略
缓存是提升系统性能的第一利器，但也是引发故障的第一杀手。缓存穿透、缓存击穿、缓存雪崩——这三大问题几乎是每个后端工程师都会遇到的挑战。本文将系统性地剖析缓存系统的设计原则、经典问题及其解决方案，从单机缓存到分布式缓存，从理论到生产实践。 Part 1: 缓存的基本原理 为什么需要缓存 存储介质 访问延迟 吞吐量 成本 CPU L1 Cache ~1 ns — 极高 CPU L3 Cache ~10 ns — 高 内存（RAM） ~100 ns ~10 GB/s 中 SSD ~100 μs ~500 MB/s 低 HDD ~10 ms ~100 MB/s 极低 网络（同机房） ~500 μs — — 网络（跨机房） ~50 ms — — 内存访问比 SSD 快 1000 倍，比 HDD 快 100,000 倍。缓存的本质就是用更快的存储介质保存热点数据的副本。 缓存的命中率 命中率 = 命中次数 / (命中次数 + 未命中次数) 命中率 效果 说明 < 50% 差 缓存几乎没有意义 50-80% 一般 有一定效果...
设计一个亿级 IM 即时通讯系统
如何设计一个支撑亿级用户的即时通讯（IM）系统？这是系统设计面试中最经典的题目之一，也是实际工程中最复杂的分布式系统之一。本文将从需求分析出发，逐步构建一个完整的 IM 系统架构，涵盖长连接管理、消息投递、在线状态、多设备同步、群聊优化等核心问题。 Part 1: 需求分析与容量估算 功能需求 功能 优先级 说明 单聊 P0 一对一实时消息 群聊 P0 多人群组消息（最大 500 人） 在线状态 P1 显示用户是否在线 消息已读 P1 已读/未读状态 多设备同步 P1 手机、电脑、平板同时在线 离线消息 P0 离线用户上线后拉取未读消息 消息类型 P0 文本、图片、语音、视频、文件 消息搜索 P2 全文搜索历史消息 推送通知 P1 离线时通过 APNs/FCM 推送 非功能需求 指标 目标 DAU 1 亿 同时在线 2000 万 消息延迟 P99 < 200ms 消息可靠性 不丢消息（at-least-once） 消息有序性 单会话内有序 可用性 99.99%（全年停机 < 53 ...
Redis 经典用例全解：从数据结构到系统设计
Redis 不只是缓存。它是一把瑞士军刀——凭借五种基础数据结构和若干扩展模块，Redis 能解决从分布式锁到社交网络、从排行榜到消息队列的几乎所有高频系统设计问题。 本文的目标是：建立一套从业务问题到 Redis 数据结构的映射思维。对于每个用例，我们都会回答三个问题： 业务问题是什么？ 需求的本质是什么操作？ 为什么选 Redis？ 相比 MySQL、MQ 等方案，Redis 的优势和代价是什么？ 怎么设计？ 用哪种数据结构，Key 怎么命名，核心命令是什么？ mindmap root((Redis 用例全景)) 基础存储 缓存策略 Cache-Aside 穿透/击穿/雪崩 分布式会话 Session 共享 验证码/短链接 分布式 ID INCR 自增 日期分段 并发控制 分布式锁 SET NX Redlock 看门狗续期 计数器与限流 ...
