2025.2 期

• 2024年我读过的10本技术书籍(Java、架构、SRE运维）：以「能让读者理解一半、剩下一半反复读」作为好书判定标准，按推荐指数和适合人群梳理 2024 年阅读的 10 本技术书——《Effective Java（第3版）》《软件架构：架构模式、特征及实践指南》《SRE 原理与实践》《SRE Google 运维解密》《分布式系统架构：架构策略与难题求解》《架构思维-从程序员到 CTO》《数据密集型应用系统设计》《高并发架构实战》《重构（第2版）》《语义软件设计》，并附作者自己读完后转化输出的实践文章链接，强调读书要结合实践才能从舒适圈进入学习圈。

2.28

• 滴滴打车如何找出方圆一千米内的乘客？揭开 GeoHash 的神秘面纱：以打车场景下海量经纬度点近邻检索为切入，讲 GeoHash 的核心原理——对经纬度分别做二分得到 0/1 串、按「先经度后纬度」逐位交错合并成 30 bit、再用 Base32 编码压缩成 6 位字符串；前缀相同位数越多代表两点空间距离越近，因此可把经纬度直接索引为字符串前缀查询，避开暴力遍历；最后点出边缘格子带来的「位距近但实际距离远」问题，留作后续优化。

• ES+MySQL优雅的实现模糊搜索：用 Elasticsearch 承担全文/模糊检索、MySQL 承担事务存储的双存储方案落地示例——在 common 模块下抽出独立 ES 公共包；对题目表同时建 @Document(indexName="idx_question") 的 QuestionES 与 MyBatis-Plus 的 Question 实体，title/content 字段用 ik_max_word 分词；通过继承 ElasticsearchRepository 写派生方法 findQuestionByDifficulty，再用 @Query 自定义 bool DSL（should 匹配 title/content、must term 过滤 difficulty、minimum_should_match:1）实现「关键词 OR + 难度 AND」组合查询；Service 层按 difficulty / keywords 是否为空走四个分支，并在 ES 首次为空时从 MySQL 全量回灌，最终以分页 VO 返回。

2.26

• 从Alibaba-Cola到DDD，一线研发对领域驱动的思考：从一线落地视角拆解 Alibaba COLA 骨架下 DDD 的六层分包职责与代码归属——domain 层是核心，承载实体/值对象/聚合/工厂/领域事件/服务接口与仓储接口定义，原则是不依赖任何其他层、避免贫血模型、按领域而非按对象类型分包；infra 层是「纯技术」实现层，存放 Mapper/XML、工具类、Spring Configuration、模型转换、仓储/服务/网关接口的实现，仅依赖 domain；app 层作为协调者编排 domain 与 infra 完成 Controller/HSF/Client 接口；adapter 层只放 Controller、统一异常、参数校验、拦截器与定时任务等薄层逻辑；client 层只暴露 RPC DTO/接口/枚举供外部依赖；并以工单系统为例演示如何识别实体/值对象与聚合行为，强调合理分层比形式完整更重要。

• 百万级群聊的设计实践：vivo 互联网团队搭建纯 H5、单群百万成员同时在线的群聊系统的服务端设计——通信选 WebSocket，存储用「读扩散」共享群信箱以规避写扩散在万人级群的写入与存储爆炸；架构上拆「连接服务（管会话+本地哈希表维护 groupId→userList）/ 群组服务（用 Redis 维护 groupId→连接服务 IP 列表，靠主动上报+定时心跳保证准确性）/ 消息队列」三层，消息走「WS→连接服务→MQ→群组服务（频控/安全/格式/落库）→HTTP 回调对应连接服务→WS 推送新消息提醒→客户端按 ID 拉详情」；用「轮询+权重」做长连接路由均衡、心跳触发断线重连与发送态消息暂存重发、IO 线程与业务线程隔离，并简述消息有序性、可靠性、未读数统计的处理思路。

• 爱奇艺的接口治理与自动化测试一体化解决方案实践：针对微服务化后接口爆炸带来的文档分散、变更通知滞后、Mock/调试/测试多工具数据不同步、自动化测试上手与维护成本高等问题，爱奇艺自研 Atlas 平台以「业务线-应用-接口」三层分级管理 + 细粒度权限 + 全局检索为骨架，以 OpenAPI 3.0 作为唯一文档契约，通过 Swagger 注解+编译插件+CI/CD 将代码即文档自动同步到平台并自动生成 Mock 地址；测试侧用可视化零代码用例编排、调试结果一键转用例、智能生成断言与脚本、CI 流水线持续回归，并将线下用例切环境直接转为线上监控；落地后接口文档维护时间归零、用例编写时间下降 50%/80%、平台与工具维护成本下降 70%、多业务核心逻辑自动化覆盖率达 100%。

2.24

• JVM 里的逻辑漏洞，居然让你的哈希表慢了 20%！：作者通过一段遍历 ConcurrentHashMap 的代码定位到 OpenJDK 23→24 性能提升 20%+ 的根因——HotSpot C2 的标量替换依赖逃逸分析与 IGVN 把对象字段读写优化成普通操作、再由宏消除删除堆分配，而 G1 GC 为维护 SATB/RSets 在写字段处插入的 post-write barrier 在 IGVN 一轮迭代中尚未被当作死代码消除前，会让 LoadNode::split_through_phi 在 MemNode::all_controls_dominate 沿控制流回溯时撞上「死胡同」、保守返回 nullptr，导致 Load 优化失败、迭代器对象被迫分配到堆上；作者提交的修复 JDK-8333334 让 all_controls_dominate 在遇到死胡同时把节点重新加回 IGVN 工作列表，等下一轮死代码被删后继续优化，patch 已合入主线并回移到 Dragonwell 21 / AJDK 21。

2.21

• 高并发下秒杀系统的设计：以电商秒杀场景拆解四类高并发方案——单表加锁（小流量）、Redis + MQ 削峰防超卖、阿里 RDS 的 Inventory Hint 技术（数据库内核合并热点行更新）、以及压力分摊（分桶/批量 SQL/分布式 + 本地 + 近端多级缓存），并重点剖析 Redis Lua 脚本原子扣减库存 + RocketMQ 事务消息同步 MySQL 的实现路径，以及 Inventory Hint 通过分组排队、Row Cache 缓存热点行、组提交三大优化点减少行锁等待与 B+ 树遍历，强调技术方案要因「量」制宜按场景组合。

• 【稳定性】稳定性建设之依赖设计：京东物流总结的稳定性建设方法论，将依赖按强弱划分为最强/强/弱/最弱四级（核心原则：去除、弱化、控制依赖，能异步弱依赖不要同步强依赖），并按业务域、系统启动、基础技术服务、数据库、部署、对外 API/MQ、硬件七类拆解依赖治理，配合 Pfinder 应用拓扑与调用链工具扫描 + 人工梳理代码走读输出强弱依赖关系，最终落地非核心故障不影响核心业务、弱依赖容错与应急预案双目标。

2.19

• 时间轮在 Netty , Kafka 中的设计与实现：基于 Netty 4.1.112 与 Kafka 3.9.0 源码对比时间轮设计，先解释 JDK Timer（小根堆 TaskQueue + TimerThread）和 ScheduledThreadPoolExecutor 在中间件「海量任务、逻辑简单、执行时间短、精度要求低」场景下的局限（O(log n) 插入、单线程瓶颈），再分别拆解 Netty HashedWheelTimer 的单层时间轮 + tickDuration + bucket 双向链表实现与 Kafka 分层时间轮（DelayQueue 驱动指针推进、跨层降级）的差异，揭示分层结构如何把任意时长任务的添加/删除均摊到 O(1)。

2.16

• 快手Java透明协程：实现零代码修改提升30%QPS：快手基于阿里 Dragonwell Wisp 协程方案自研 Java 17 透明协程，解决云原生 K8s CPU 受限下线程 CFS 调度引发 CPU Throttle 的核心痛点（平均 RT 从 101ms 降到 63ms），通过 WispCarrier 调度器 + IO/Timer/Locker 管理模块的架构改造，针对原生方案在低负载下 CPU 劣化 10%、长任务抢占开销大、JNI 无法及时抢占、IO 查询不及时四类缺陷做调度 CPU 优化（线程数最小化、减少 Context-Switch）、抢占机制升级与 IO 管理优化，实现业务零代码修改下 QPS 提升 30% 以上。

• 面试官：说说30亿量级的表结构，你是如何设计的：以财务系统科目余额场景演示大表设计方法论，强调先做业务需求分析（账套/科目/凭证/会计期间等概念）与数据量预估（每年凭证分录 40 亿、按期间存全量余额每年 36 亿），再基于 TiDB 分布式数据库拟定三个备选方案：不落库实时计算、全字段按期间落库、仅落「凭证发生的科目 + 本期发生额」（数据量缩减 5-10 倍至 7 亿/年），从实现复杂度、性能瓶颈、查询路径维度对比择优，得出表结构与索引是结果，业务分析与技术方案设计才是 30 亿量级表设计关键的结论。

• 读写锁 + HashMap 超级组合，真心推荐！：用 RocketMQ NameServer 路由表为案例讲解 ReentrantReadWriteLock + HashMap 的编程范式（封装类内读操作加读锁、写操作加写锁），通过两个堆栈实验验证读读不互斥、读写互斥、写写互斥的特性，并对比 ConcurrentHashMap——操作多个 HashMap 需要整体一致性时（如 NameServer 多张路由表同步更新）必须用读写锁，单个 HashMap 场景下 JDK 1.8 ConcurrentHashMap 凭 CAS 优化在性能上优于读写锁方案。

2.15

• 工作中最常用的 8 种设计模式：列举工作中高频使用的 8 种设计模式并结合 JDK/Spring 源码场景说明应用——单例（双重检查锁、Spring Bean 默认单例、Runtime）、工厂（BeanFactory、Calendar.getInstance）、策略（Comparator、Spring 事务管理）、代理（JDK Dynamic Proxy、Spring AOP）、观察者（Spring ApplicationEvent）、装饰器（IO 流体系）、模板方法（JdbcTemplate、AbstractList）、建造者（StringBuilder、Lombok @Builder），每种模式给出最简代码示例与典型应用入口。

2.14

• 「缓存」会用很容易，用好才是技术活：阿里云开发者从两个真实大促事故（缓存失效击穿无索引慢查询拖垮数据库、Tair 预发/线上未隔离导致错误配置污染线上）切入，先讲缓存从本地→分布式→多级的演进与选型策略（频繁变更走集中式、低频变更或弱一致走本地），再对比 Guava Cache / Ehcache / Caffeine 三框架特性，详解 Guava Cache 的 CacheBuilder API（initialCapacity、maximumSize、expireAfterWrite、refreshAfterWrite、CacheLoader）与 LocalCache 的 Segment 分段 ConcurrentHashMap 数据结构，最后给出 Tair 分布式缓存使用注意事项与防穿透/雪崩/击穿建议。

• 缓存之美：万文详解 Caffeine 实现原理（上）：京东云开发者基于源码深度解析 Caffeine 固定大小驱逐策略实现，先讲整体架构：ConcurrentHashMap 存数据 + 窗口区/试用区/保护区三个 LRU 双端队列管理生命周期、TinyLFU + Count-Min Sketch 数据结构以 93.75% 准确率低内存记录访问频率优先驱逐冷数据、ReadBuffer/WriteBuffer 采用 MPSC 多生产者单消费者模式 + WAL 思想异步批量执行；再从 LocalCacheFactory 反射动态拼接类名（SSMS/SSMW 等组合）创建 BoundedLocalCache 切入，详解 put 添加元素与 maintenance 维护方法（drainReadBuffer、drainWriteBuffer、evictEntries、climb）的协作流程。

• 本地缓存 Caffeine 中的时间轮（TimeWheel）是什么？：作为 Caffeine 源码解析续篇聚焦 expireAfter 自定义过期策略的 TimeWheel 实现，先区分 expireAfterAccess/expireAfterWrite（遍历访问/写顺序队列对比时间）与 expireAfter（基于分层时间轮）的差异，再从 maintenance → expireEntries → expireVariableEntries → TimerWheel#advance 的调用链切入，剖析分层时间轮（秒/分/时/天）循环缓冲区 + bucket 双向链表的结构、indexOf 定位 bucket 的位运算、advance 推进指针时高层 bucket 任务级联降级到低层的机制，实现 O(1) 添加/删除/触发过期事件的均摊复杂度。

2.11

• 聊聊对象池框架 commons pool2：以 Apache Commons Pool2 为例讲解对象池化技术，从 PooledObjectFactory 接口（makeObject / destroyObject / validateObject / activateObject / passivateObject）、GenericObjectPoolConfig 配置（maxTotal、maxIdle、testWhileIdle）到借用归还的基本用法，再以 Jedis 连接池为实例延伸到 GenericObjectPool 源码，剖析 idleObjects（LinkedBlockingDeque）与 allObjects（ConcurrentHashMap）双容器结构，以及 borrowObject / returnObject 中的对象创建、激活、校验、销毁流程。

2.10

• 以史为鉴，未雨绸缪：身处"大模型掀起的AI浪潮中"的感悟和思考：阿里同学从专家系统、机器学习、深度学习到大模型四次 AI 技术革新的历史视角切入，系统梳理百模大战格局、Transformer / Attention / RLHF 等大模型核心理论与训练范式，再结合 AICON 现场所闻介绍大模型在搜广推、向量数据库、办公提效等领域的落地实践与安全可控难题，最终给出「拥抱大模型、取其精华知其弊端、沉淀 AI 不可替代经验」的从业者态度。

• Apache Calcite 快速入门指南：基于 Calcite 1.35.0 源码的入门指南，先讲清 Calcite「One Size Fits All」的动态数据管理框架定位与 JDBC Server / SQL Parser / Validator / Expression Builder / Query Optimizer 架构分层，再用官方 CSV 案例从 model.json 元数据注册、CsvSchemaFactory 与 SCANNABLE / FILTERABLE / TRANSLATABLE 三种表类型切入，串联起 SqlNode 校验、RBO / CBO 优化规则改写到最优执行计划落地的完整执行流程。

• 面试官问我：自己写String类，包名也是java.lang，这个类能编译运行成功吗？：以「自写 java.lang.String 能否编译运行」这道面试题为切入点，给出「能编译但运行时找不到 main 方法」的结论——双亲委派机制让 BootstrapClassLoader 优先加载 JDK 自带 String，再据此串讲 Java 编译过程（.java → .class、javap 反汇编）、类加载的加载 / 验证 / 准备 / 解析 / 初始化五步以及触发初始化的六种主动使用场景。

2.9

• 高质量编写非功能性代码的一些实践：以 Java 编码视角讨论易被忽视的非功能性质量交付，围绕四对易混淆概念给出实践建议——注释 vs JavaDoc vs 代码自注释（受众、视角、维护成本差异）、异常信息 vs 异常日志（运行时瞬时信息 vs 持久维护数据）、程序异常 vs 业务错误（健壮性范畴 vs 业务满足度范畴，错误码 vs 异常类型的选用）、标准化 vs 特例化（全局最优 vs 局部最优的权衡），每对均配 Spring 源码案例佐证。

2.8

• Spring容器的本质：以最小依赖工程从 ClassPathXmlApplicationContext 入口跟踪 Spring IoC 容器启动核心流程，串讲 ApplicationContext 继承体系（资源 / 消息 / 事件 / 环境 / 工厂五大能力）与 DefaultListableBeanFactory 收敛的 BeanFactory + BeanDefinitionRegistry + AliasRegistry 能力，重点拆解 refresh() 方法的 prepareRefresh → obtainFreshBeanFactory → invokeBeanFactoryPostProcessors → registerBeanPostProcessors → finishBeanFactoryInitialization 链路，揭示「容器本质是存放 BeanDefinition 的注册表，使用时反射创建并初始化属性」。

2.7

• 高并发编程知识体系：自底向上重构 Java 并发编程知识体系，从并发 / 并行、同步 / 异步、阻塞 / 非阻塞与 Amdahl / Gustafson 量化模型起步，依次讲解原子性 / 可见性 / 有序性三大原则与 JVM 内存模型、线程生命周期与 interrupt / wait / notify / park / join / yield 等 API、线程交互与线程安全设计技术（无状态、ThreadLocal、不可变、消息传递、JUC 容器、synchronized、volatile），再到 ReentrantLock / Condition / Semaphore / ReadWriteLock / CountDownLatch / CyclicBarrier / LockSupport 同步工具与 ThreadPoolExecutor 线程池，最终延伸到并发模式与响应式编程演进。

• 漫谈DeepSeek及其背后的核心技术：从 DeepSeek 公司背景与 V2.5 / V3 / R1 模型能力切入，重点拆解 V3 训练成本仅 600W 美元的技术内因——MLA 多头潜在注意力通过 KV 低秩联合压缩大幅削减 KV Cache、DeepSeekMoE 用细粒度专家 + 共享专家 + 无辅助损失负载均衡策略解决专家不均衡、HAI-LLM 框架的 DualPipe 流水线并行实现前向反向计算与 all-all 通信重叠、FP8 混合精度训练 + 细粒度量化 + FP32 累加保精度，以及 Prefilling / Decoding 分离 + EP320 跨机分布式推理部署方案。

2.2

• 如何快速同步第三方平台数据？：针对「同步 34 省市 8 种业务数据」场景给出端到端方案，历史数据采用 SFTP 同步（搭建 /data/{省市} 子目录的账号权限隔离、约定 省市拼音_日期.txt 固定长度文件格式、job 多线程解析入库），增量数据走「我方统一上报接口 + 单次 500 条限制 + Redis 限流（单系统 10/s、整体 500/s）+ MQ 异步落库 + 死信队列重试」实时方案，数据一致性通过 T+1 凌晨对账 job 比对昨日 SFTP 增量 txt 与库内数据并按修改时间过滤今日变更解决。

2.1

• 万字图文：应用架构设计、应用服务、应用结构、应用交互设计：以 SaaS 系统骨架为视角系统讲解应用架构三要素——应用服务（参考 DDD 限界上下文与业务能力地图划分粒度，围绕业务对象聚合相关功能）、应用结构（按系统级 / 应用级 / 模块级 / 代码级分层管理复杂度，遵循服务边界 + 技术痛点 + 10-12 人团队规模三大划分原则、避免过早拆分与循环依赖）、应用交互（基于 DDD 上下文映射定义上下游关系，权衡同步调用与异步消息），并以新零售 SaaS 全局结构（用户端 / 解决方案 / 业务系统 / 共享服务 / 技术平台 / 基础设施六层）和订单履约系统四层结构作为落地示例。