三个月周度学习规划（含资源映射 + 问题集）+ 两个项目详细设计（学习成果验证 / 南向通信适配）

目标：面向工作（Java + 网络通信底层能力）快速形成“可落地工程能力 + 可回溯系统原理”的主线；为工作一年后读研保留可研究化空间。
你已拥有的核心教材非常齐全，本规划将每一块学习内容明确绑定到你的书单（必要时补充 RFC/官方文档作为“标准源”）。

0. 执行规则（确保三个月真的有效）

每周最低交付物（硬性）

  1. 知识结构图：本周主题一张图（Markdown/手绘均可）
  2. 问题集答卷：本周问题集“闭卷作答”并自评（可用 Markdown）
  3. 实验/代码提交：至少一次可复现的实验记录或可运行代码（含结论）
  4. 复盘文档：1–2 页《现象—原因—验证—结论》

资源使用原则

  • 教材只抓主线：按“本周主题”读对应章节，不追求封面到封底。
  • RFC/标准文档当作“权威定义”：尤其你未来做南向协议能力，标准意识很关键。
  • 所有学习都要落到：能解释 + 能复现 + 能量化（指标/对比）。

1. 12 周学习规划（按周）——每周包含：目标 / 资源 / 实践 / 问题集

资源缩写说明（全部来自你的书单）：

  • CO-DESIGN：《计算机组成与设计：硬件/软件接口 RISC-V 版 第2版》
  • CO-STRUCT：《计算机组成 结构化方法（Tanenbaum，第6版）》
  • OS-OSTEP：《操作系统导论》
  • OS-CONCEPTS：《操作系统概念（第9版等）》
  • NET-KUROSE：《计算机网络 自顶向下（Kurose/Ross 第7版）》
  • NET-TANEN：《计算机网络（Tanenbaum 第6版）》
  • DB-CONCEPTS：《数据库系统概念（第7版）》
  • INNODB：《MySQL技术内幕：InnoDB存储引擎（第2版）》
  • HPMYSQL：《高性能MySQL（第4版）》
  • SQL：《SQL必知必会（第5版）》
  • REDIS-BP：《Redis最佳实践与实战指南》
  • REDIS-IMP：《Redis设计与实现》
  • （可选）PRAG：《程序员修炼之道》

Week 1：系统全景 + Java 执行链路（从源码到 CPU 的解释闭环）

目标

  • 建立“硬件—OS—JVM—应用”的统一心智模型
  • 能清晰解释：编译、类加载、字节码、JIT、系统调用的边界

资源

  • CO-DESIGN：绪论 + 指令/执行基本概念（建立层次图即可）
  • OS-OSTEP：导论（OS 提供的抽象与目标）
  • PRAG（可选）：工程习惯（输出/复盘方式）

实践

  • 写 3 个小程序：溢出、浮点误差、数组访问
  • 输出：《一行 Java 代码从 .java 到 CPU 发生了什么》（图 + 文）

问题集（闭卷）

  1. JVM 与 OS 的职责边界是什么？各举 3 个例子。
  2. .class 到机器码之间发生了哪些阶段？JIT 的价值与风险是什么？
  3. 为什么 int 溢出不报错？工程上如何规避风险？
  4. 浮点误差的根因是什么？在工程里有哪些规避策略？
  5. 你如何证明 A 比 B 更快？需要哪些指标、对照组、预热策略？

Week 2：组成核心（存储层次/局部性/Cache）——为性能直觉打底

目标

  • 获得“访问模式决定性能”的直觉
  • 能解释：Cache/局部性/带宽与延迟的差异

资源

  • CO-DESIGN：存储层次、Cache 基本机制（映射/命中/替换的概念层）
  • CO-STRUCT：性能与层次存储相关章节（补“为什么”）

实践

  • 顺序访问 vs 随机访问基准实验（记录结果与原因）
  • 实现一个 LRU Cache（自写）：命中率/淘汰次数统计

问题集

  1. 为什么 Cache 有效？时间/空间局部性分别是什么？
  2. 顺序遍历数组比链表快的根因是什么（不仅是 O( )）？
  3. Cache 命中率与系统吞吐之间的关系是什么？
  4. 你实现的 LRU 为什么能近似局部性？在什么工作负载下会失败？

Week 3：虚拟内存/分页/TLB（组成→OS 的关键桥梁）

目标

  • 能解释：虚拟内存为何诞生、分页如何工作、缺页的代价是什么
  • 形成“地址空间/保护/共享”的 OS 视角

资源

  • OS-OSTEP：虚拟化内存、分页相关章节
  • OS-CONCEPTS：内存管理章节（用于补全术语与框架）

实践

  • 做一次“内存压力实验”：观察缺页/抖动现象（可用 Linux VM 更直观）
  • 输出《缺页发生时系统做了什么》（流程图）

问题集

  1. 虚拟内存解决了哪些问题？又引入了哪些开销？
  2. 缺页中断的处理流程（概念级）是什么？
  3. TLB 的价值是什么？它为什么“很小也很重要”？
  4. 页面置换为什么会导致抖动？如何缓解？

Week 4：进程/线程/系统调用 + Java 并发基础（贴近工作）

目标

  • 理解线程模型、上下文切换成本
  • 能解释：为什么线程池是工程必需品

资源

  • OS-OSTEP：进程/线程、调度导论、系统调用相关章节
  • OS-CONCEPTS：进程/线程章节（补齐概念框架）

实践

  • 多线程计数对比：无锁 / synchronized / Atomic / LongAdder
  • 用工具观察线程状态（jstack/jcmd/JFR 任意其一）

问题集

  1. 进程与线程的核心差异是什么？为什么线程更轻？
  2. 上下文切换保存/恢复了什么？为什么会影响吞吐与延迟？
  3. 阻塞/非阻塞、同步/异步分别是什么？请各举 2 个例子。
  4. 为什么“线程越多越快”是错的？给出至少 3 个原因。

Week 5：同步、死锁、并发控制（锁/AQS 思维）+ 自实现并发组件

目标

  • 掌握并发正确性与工程权衡
  • 能实现并解释：阻塞队列/线程池核心机制

资源

  • OS-OSTEP：锁、并发、死锁章节
  • OS-CONCEPTS：同步与死锁章节（系统性框架）

实践

  • 自实现 有界阻塞队列（put/take + 超时可选）
  • 写死锁示例并用 jstack 定位（输出定位步骤）

问题集

  1. 死锁四个必要条件是什么？如何破坏其中一个？
  2. 自旋锁 vs 阻塞锁适用场景分别是什么？为什么？
  3. 为什么 wait/notify 需要在同步块里调用？
  4. 你实现的阻塞队列如何保证：不丢任务、不忙等、可唤醒？

Week 6：JVM 内存/GC 与工程稳定性（为“线上表现”负责）

目标

  • 能解释：GC 与尾延迟、吞吐之间的关系
  • 能用日志/数据支撑结论（而不是感觉）

资源

  • OS-OSTEP：内存相关回看（理解 OS/JVM 的交界）
  • （补充标准源）OpenJDK / Java 官方文档：GC、JFR、jcmd（不要求精读，只为查证）

实践

  • 写 GC 压力程序：分别触发 Young GC 与 Full GC（或接近 Full）
  • 收集 GC 日志 / JFR 并写《现象—原因—建议》

问题集

  1. Full GC 常见触发路径有哪些？
  2. STW 是否可避免？为什么？
  3. 为什么尾延迟（p99）对工程比平均值更重要？
  4. 如何通过参数/对象分配策略减少 GC 压力？举 3 个做法。

Week 7：网络基础（TCP/IP）+ IPv4/IPv6（与你岗位强相关）

目标

  • 能解释 TCP 可靠性、重传、窗口、拥塞控制
  • 理解双栈与 IPv6 的关键机制（后续协议能力必备）

资源

  • NET-KUROSE：运输层（TCP）+ 网络层（IP）章节
  • NET-TANEN：TCP/IP 机制补充（更偏实现视角）
  • RFC（标准源，建议精读摘要/关键段）
    • TCP：RFC 9293（现代 TCP 规范汇总）
    • IPv6：RFC 8200
    • Neighbor Discovery：RFC 4861

实践

  • 抓包：三次握手 + 四次挥手 + RST（写 1 页解析）
  • IPv6：本地/VM 完成一次 IPv6 socket 连通测试（记录环境）

问题集

  1. TCP 为什么可靠？它不保证什么？
  2. 三次握手每一步目的是什么？为什么不是两次？
  3. TIME_WAIT 为什么存在？对服务端有什么影响，如何治理？
  4. 流量控制 vs 拥塞控制的区别是什么？
  5. IPv6 ND 为什么能替代 ARP？工程上常见坑是什么？
  6. 双栈环境优先 IPv6 还是 IPv4？失败回退怎么设计？

Week 8：网络编程模型（BIO/NIO/事件驱动）+ 可观测性最小集合

目标

  • 能写出可承载大量连接的网络服务骨架
  • 具备“可观测性意识”（你未来做南向通信会非常依赖）

资源

  • NET-KUROSE：应用层 + 运输层相关回看（为编程服务）
  • （补充）Java NIO 官方文档 / Netty 用户手册（用于落地实现）

实践

  • 写一个 NIO/Selector 或 Netty Echo/协议框架 Demo
  • 增加：延迟统计、失败率、队列深度等指标（先用日志也可）

问题集

  1. I/O 多路复用为什么能支撑高并发连接？节省了什么？
  2. Reactor 模式核心组件有哪些？事件循环在做什么？
  3. BIO 什么时候反而更合适？
  4. 你认为可观测性最小集合是什么？各解决什么问题？
  5. 99 线延迟飙升，你的排查路径是什么（按步骤写）？

Week 9：数据库（索引/SQL）——为“协议平台数据落地”做准备

目标

  • 能用 explain/慢日志定位 SQL 性能问题
  • 形成索引设计的工程直觉

资源

  • SQL：覆盖查询语法与基本用法（作为练习题库）
  • DB-CONCEPTS：关系模型、索引、查询优化基本思想
  • HPMYSQL：性能视角与诊断方法
  • INNODB：InnoDB 架构与索引/事务实现视角（为 Week10）

实践

  • 建表 + 写 20 条 SQL（单表/连接/聚合/子查询）
  • 索引对比实验：有/无索引，记录 explain 与耗时

问题集

  1. B+Tree 为什么适合磁盘？与 B-Tree 差异的工程意义？
  2. 什么是回表？覆盖索引如何减少回表？
  3. 联合索引最左前缀原则如何影响查询设计？
  4. Explain 里你重点看哪些字段？各代表什么？
  5. 当你只能加一个索引时，如何决策？

Week 10：事务与并发控制（InnoDB/MVCC）——工程一致性的核心

目标

  • 能解释 RC/RR、读现象、MVCC
  • 能处理死锁、冲突、重试与幂等

资源

  • DB-CONCEPTS：事务、隔离级别、并发控制
  • INNODB：MVCC/锁/事务实现（看“现象层+机制层”）
  • HPMYSQL：死锁、慢事务、诊断与治理

实践

  • 并发转账：RC vs RR 对比（记录现象与原因）
  • 制造死锁：定位、重试、幂等策略（输出一份复盘）

问题集

  1. RC 与 RR 的差异是什么？分别会出现哪些读现象？
  2. MVCC 的核心思想是什么？它如何减少读写冲突？
  3. 死锁的常见触发模式有哪些？工程上如何减少？
  4. 幂等性为什么重要？你至少给出 3 种实现方式。
  5. 分布式环境里事务为什么更难？至少说 3 个原因。

Week 11：项目一启动（学习成果验证）——把 Week1–10 串成闭环

目标

  • 做一个可压测、可定位瓶颈、可解释原理的高并发服务系统
  • 让“线程池/缓存/DB/观测”在一个链路里跑起来

资源

  • 回看：OS 并发 + 网络编程 + DB 索引/事务
  • （可选）REDIS-BP：缓存工程化实践（如你加入 Redis）

实践

  • 完成项目一 MVP（见第 2 部分：项目一设计）
  • 形成第一次压测报告（哪怕很粗也要有数据）

问题集

  1. 你系统瓶颈最可能在哪里？为什么？
  2. 线程池参数如何选？给出估算方法与验证方法。
  3. 你如何证明优化有效？对照组怎么做？
  4. p99 飙升，你先查什么？按步骤写出排查路径。

Week 12：项目二启动（南向通信适配）+ 双项目收敛与报告化

目标

  • 以“南向协议网关/采集器”形态提前适应工作内容：
    SNMP / Telemetry / SSH / Telnet + IPv4/IPv6 + 稳定性/可观测性/背压
  • 双项目最终交付：能演示、能复盘、能扩展

资源

  • 网络：NET-KUROSE + 相关 RFC（见项目二）
  • 协议标准源（建议至少阅读 Overview/术语/报文结构）：
    • SNMP：RFC 3411–3418（体系与框架）
    • SSH：RFC 4251（架构）
    • Telnet：RFC 854（基本协议）
    • IPv6：RFC 8200；ND：RFC 4861
    • Telemetry：若走 gRPC/Protobuf 可参考 gRPC/Protobuf 官方文档；若走自定义 TCP 则你自定义协议为准

实践

  • 项目二完成骨架 + 至少 2 个协议适配器（优先 SNMP + SSH）
  • 输出两份最终文档：
    1. 《系统瓶颈定位与优化复盘》（项目一）
    2. 《南向通信网关设计说明与扩展点》（项目二）

问题集

  1. 若要扩到 10 万设备，你最先改哪里？为什么？
  2. 如何设计连接生命周期（心跳/超时/重连/退避）避免雪崩？
  3. 你如何做背压？队列满时怎么办？丢弃/降采样/落盘如何选？
  4. 双栈下 IPv6 优先与失败回退如何实现并可观测？
  5. 你如何把项目二“实验化”变成未来读研可研究问题？举 2 个。

2. 项目一：学习成果验证项目（SystemCore-Bench）

2.1 定位

一个可压测、可定位瓶颈、可解释原理的 Java 高并发服务系统
重点验证：线程池/并发正确性/IO 模型/缓存/数据库事务与索引/可观测性/性能分析。

2.2 功能范围（建议最小业务：Event/Metric 服务）

  • API（建议 HTTP；若你想更贴近底层，可自定义二进制协议二选一）
    • POST /events：写事件（落库 + 可选缓存更新）
    • GET /events/{id}：读事件（cache → db）
    • GET /stats：输出系统指标（QPS、p99、队列深度、拒绝数、GC 概览等）

2.3 必做模块（“手写部分”是验收关键）

  1. 自实现线程池
    • Worker 生命周期、有界队列、至少 2 种拒绝策略
    • 指标：activeCount、queueSize、rejectCount、taskLatency
  2. 自实现 LRU Cache
    • HashMap + 双向链表 + 命中率统计
    • 并发策略：先全局锁（可用），再考虑分段锁（加分）
  3. 数据库访问层
    • MySQL（InnoDB）+ 事务 + 索引
    • 连接池可用成熟实现（工程合理），重点在事务/SQL/索引决策
  4. 可观测性
    • 指标（最少）：QPS、p99、失败率、队列深度、拒绝数、DB耗时分布
    • 日志：结构化字段（requestId、traceId 可选）

2.4 工程验收标准（你用它自证“学会了”）

  • 正确性：并发写入不丢、不乱；支持幂等（至少一种方案）
  • 性能：输出压测结果（吞吐/延迟/资源），并能解释瓶颈
  • 优化：至少做 2 次优化并对比（索引/缓存/线程池/减少锁竞争等）
  • 复盘：形成《现象—原因—验证—结论》报告（可复现）

2.5 推荐技术选型（务实）

  • 网络：JDK NIO 或 Netty（更工程化）
  • 存储：MySQL +（可选 Redis，用于对比“本地缓存 vs 分布式缓存”）
  • 压测：wrk/JMeter/自写 loadgen（任选一个，但要能复现）

2.6 推荐里程碑（配合 Week 11）

  • M1：请求链路跑通（API→线程池→业务→DB→响应）
  • M2：LRU 缓存接入，输出命中率与 p99
  • M3：事务/索引优化一次，形成对比报告
  • M4：稳定性措施（限流/快速失败/降级）至少一个落地
  • M5：最终压测与复盘文档

3. 项目二：南向通信能力构建适配项目（Southbound-Gateway）

3.1 定位

一个南向协议网关/采集器平台（Java），支持 SNMP / Telemetry / SSH / Telnet，兼容 IPv4/IPv6，强调连接管理、稳定性、背压与可观测性。

这类系统的工程“生死线”不是功能，而是：
连接生命周期 + 速率控制/背压 + 故障恢复 + 可观测性。

3.2 系统边界（你要实现的核心能力）

  • 统一设备抽象：屏蔽协议差异
  • 协议适配器插件化：SNMP/SSH/Telnet/Telemetry 作为 adapter
  • 连接与会话管理：心跳、超时、重连、退避
  • 任务调度与限速：按 device/site/protocol 限速，避免雪崩
  • 背压策略：下游慢时明确处理（丢弃/降采样/落盘队列）
  • 可观测性：指标/日志让你能“看见系统在做什么”
  • 双栈支持：IPv4/IPv6 统一表示、优先级与回退可配置

3.3 推荐架构

Northbound（REST/CLI）

|

Core（任务调度/限速/重试/背压/状态机）

|

Adapters（SNMP / SSH / Telnet / Telemetry）

|

Storage（MySQL/文件/TS 可选） + Observability（metrics/log）

3.4 关键数据模型（建议）

  • Device(deviceId, name, addresses[v4/v6], credentialsRef, tags, capabilities)
  • Task(taskId, deviceId, type[poll/command/stream], schedule, timeout, retries, backoff, rateLimitKey)
  • Result(deviceId, taskId, timestamp, status, latency, payload, errorCode, meta)
  • Session(deviceId, protocol, state, lastSeen, reconnectCount, addressFamilyUsed)

3.5 协议能力落地建议（按优先级）

三个月内建议完成：SNMP + SSH +（Telemetry 或 Telnet）
全都做很可能摊薄质量；南向岗位更看重“稳定性与架构可扩展”。

A) SNMP（Polling + Trap）

  • 建议 Java 库：SNMP4J
  • 能力拆解
    • Poll：GET + WALK（至少 GET，WALK 加分）
    • Trap：UDP Listener（可选但很加分）
  • 工程重点
    • 超时/重试（指数退避）
    • 轮询速率控制（按设备分桶）
    • Trap 风暴保护（限流/聚合/采样）

标准源（建议阅读框架与术语）

  • SNMP 体系：RFC 3411–3418

B) SSH（命令通道）

  • 建议 Java 库：Apache Mina SSHD（更工程化）
  • 能力拆解
    • 会话复用（session pool）
    • 命令执行：超时/中断、输出采集
  • 工程重点
    • 同一设备的并发控制（串行或限并行）
    • 凭据管理（credentialsRef，不硬编码）

标准源

  • SSH 架构：RFC 4251

C) Telnet（兼容性通道）

  • 建议库：Apache Commons Net
  • 能力拆解
    • 登录交互（提示符识别）
    • 命令执行（输出读取、超时）
  • 工程重点
    • 风险边界（不安全）：在文档里明确使用范围

标准源

  • Telnet：RFC 854

D) Telemetry（Streaming）

你的岗位里 Telemetry 可能是持续上报。三个月内建议先做“可运行、可背压、可恢复”的骨架。

  • 推荐实现路线（由易到难）
    1. 自定义 TCP Streaming（长度字段 framing + 解码 + 入库）
    2. 升级：gRPC + Protobuf（更贴近主流 Telemetry）
  • 工程重点
    • 背压：下游慢时策略（丢弃/降采样/落盘队列）
    • 断线重连与会话恢复

3.6 IPv4/IPv6 双栈设计要点（必须显式设计）

  • 地址模型：使用标准表示（不要“一个 String ip”糊弄）
  • 策略：
    • 优先 IPv6（可配置），失败回退 IPv4（记录原因）
  • 可观测：
    • 日志/指标必须记录 addressFamily、解析耗时、连接耗时、失败码

标准源

  • IPv6：RFC 8200
  • Neighbor Discovery：RFC 4861
  • TCP：RFC 9293

3.7 稳定性能力（南向系统必做）

  1. 任务调度器：固定间隔轮询/cron
  2. 限速：按 device/site/protocol 限速（防止集中打爆）
  3. 重试退避：指数退避 + 最大上限 + 抖动（jitter）
  4. 背压：队列满的处理策略必须明确并可观测

3.8 可观测性最小集合（建议直接做成指标）

  • poll_success_total / poll_fail_total
  • protocol_latency_p99{snmp/ssh/telnet/telemetry}
  • reconnect_total
  • queue_depth
  • drop_total（背压导致）
  • ipv6_preferred_success_rate（双栈效果）

3.9 仿真与测试环境（让它“像工作”）

  • SNMP：snmpsim / net-snmp agent（模拟设备）
  • SSH：本地 sshd（VM/容器）
  • Telnet：telnetd（VM/容器）
  • Telemetry：自己写 device-sim 持续上报
  • IPv6：VM 开 IPv6，至少一次端到端连通与协议请求

3.10 里程碑建议（配合 Week 12）

  • M1：设备模型 + 调度 + 指标框架
  • M2：SNMP polling + SSH 命令通道跑通
  • M3：限速 + 重试退避 + 背压策略落地
  • M4：Telemetry（或 Telnet）补齐；双栈策略验证
  • M5：交付文档 + 故障演示（断连/超时/队列满/风暴）

4. 两项目如何共同服务你的主线目标（建议你写在 README 第一段）

  • 项目一（SystemCore-Bench）：证明你掌握通用系统能力（并发/缓存/DB/性能/观测）
  • 项目二（Southbound-Gateway）：提前适应南向通信能力构建（协议/连接/稳定性/双栈/背压）
  • 共同点：都必须“可解释、可复现、可量化”.