在 Java 开发中，HashMap 是高频使用的集合类，从业务缓存到框架底层都离不开它，但多数开发者对其理解仅停留在 “键值对存储”，对 “为何高效”“为何踩坑” 的底层逻辑一知半解。面试中 “JDK1.7 与 1.8 的 HashMap 有何不同”“链表为何转红黑树”，开发中 “扩容导致性能波动”“哈希冲突引发查询变慢”，这些问题的答案，都藏在 HashMap 的底层设计里。它不是简单的 “数

在微服务架构中，服务被拆分为独立、分布式的单元，彼此通过网络调用协作。这种架构虽提升了灵活性，但也引入了故障扩散、流量过载、安全漏洞、数据不一致等风险。因此，微服务的保护本质是：通过一系列技术手段和策略，保障微服务集群的可用性、安全性、可靠性，避免单个服务的问题影响整体系统，同时确保数据和接口的安全。微服务保护并非单一机制，而是覆盖 “服务运行、接口交互、数据存储、安全访问” 全链路的体系化方案。

在微服务架构中，业务逻辑被拆分为多个独立服务，一次完整业务流程往往需要跨多个服务调用（如订单服务调用库存服务、支付服务）。此时传统单机数据库的 ACID 事务已无法满足需求 —— 若某一环节调用失败（如支付成功但库存扣减失败），会导致各服务数据不一致，这就是分布式事务问题。

在 JVM 中，垃圾收集器（GC）的设计目标差异显著，主要体现在吞吐量、延迟、内存支持规模、线程模型等核心特性上。小型应用 / 嵌入式：优先 Serial GC；吞吐量优先（批处理）：Parallel GC；中大型应用（平衡吞吐与延迟）：G1（默认选择）；超低延迟 + 大内存：ZGC 或 Shenandoah（根据 JDK 版本和生态选择）。实际使用中需结合堆大小、CPU 核心数、延迟要求进行压测

维度三次握手（建立连接）四次挥手（关闭连接）核心目标双向确认收发能力，协商 ISN、MSS、Window双向关闭连接，确保双方数据均传输完成状态流转客户端：CLOSED→SYN_SENT→ESTABLISHED服务器：CLOSED→LISTEN→SYN_RCVD→ESTABLISHED客户端：ESTABLISHED→FIN_WAIT_1→FIN_WAIT_2→TIME_WAIT→CLOSED服务器