Java on Orangex-position0的技术博客

接口 + 抽象模板组合模式：让子类只写核心逻辑

Sat, 11 Apr 2026 10:00:00 +0800

🤔 你是否在子类里写了大量重复的"流程代码"？

假设你有三个业务 Service：订单服务、支付服务、库存服务。它们各自的 apply() 方法看起来是这样的：

public class OrderService {
 public Result apply(Request request) {
 validate(request); // 参数校验
 initContext(); // 初始化上下文
 try {
 Result result = doOrder(request); // ← 唯一不同的部分
 postProcess(result); // 后置处理
 return result;
 } catch (Exception e) {
 handleError(e); // 异常处理
 throw e;
 } finally {
 cleanUp(); // 资源清理
 }
 }
}

把上面代码里的 doOrder 换成 doPayment、doInventory，你会发现流程完全一样，只有核心业务逻辑那一行不同。

⚠️️这就是问题所在：相同的流程控制代码在每个子类中重复出现。如果某天需要在所有服务中增加一个"日志记录"步骤，你得挨个修改每一个 Service。

本文将介绍一种接口 + 抽象模板的组合模式，让通用流程只写一次，子类只需关注自己的核心逻辑。

读完本文，你将了解：

“接口定义契约 + 抽象模板控制流程"的组合设计思想
Spring 的 JdbcTemplate 是如何运用这一思想的

🏗️ 核心思想：三层分工

这个模式的核心可以用一句话概括：

接口定义契约，抽象模板控制流程，子类专注实现具体逻辑。

三个角色各有明确的职责边界：

角色	职责	关键手段
接口	定义"做什么”——对外暴露的业务契约	声明 `apply()` 方法
抽象模板类	定义"怎么做"——控制不可变的通用流程	实现 `apply()` 为 `final`，内部调用 `doApply()`
具体子类	实现"做哪样"——只填入核心业务逻辑	重写 `protected doApply()`

为什么不能只用接口或只用抽象类？

只用接口：无法复用流程代码，每个实现类都要重复写一遍 validate → try → do → catch → finally。
只用抽象类：可以实现模板方法，但一个类只能单继承，限制了灵活性。而且调用方无法面向接口编程。
接口 + 抽象类组合：接口提供了多态和面向接口编程的能力，抽象类提供了流程复用的能力。两者互补。

🛠️ 一步步实现组合模式

第一步：接口定义业务契约

接口只关心"能做什么"，不关心"怎么做"：

public interface BusinessService {
 Result apply(Request request);
}

这个接口是对外的契约。调用方只需要知道 BusinessService 有一个 apply() 方法，不需要知道背后是哪个具体实现。

第二步：抽象模板封装通用流程

这是整个模式的核心。抽象类实现接口，把不可变的流程写死在 apply() 中，把可变的部分留给子类：

public abstract class AbstractBusinessTemplate implements BusinessService {

 // 声明为 final，子类不能覆盖流程
 @Override
 public final Result apply(Request request) {
 validateRequest(request);
 initializeContext();

 try {
 // 核心：调用子类实现的具体逻辑
 Result result = doApply(request);

 postProcess(result);
 return result;
 } catch (Exception e) {
 handleException(e);
 throw e;
 } finally {
 cleanUp();
 }
 }

 // 子类必须实现的抽象方法
 protected abstract Result doApply(Request request);

 // 以下通用方法提供默认实现，子类可选择性覆盖
 protected void validateRequest(Request request) {
 if (request == null) {
 throw new IllegalArgumentException("Request cannot be null");
 }
 }

 protected void initializeContext() { /* 默认实现 */ }

 protected void postProcess(Result result) { /* 默认实现 */ }

 protected void handleException(Exception e) {
 // 默认异常处理，比如记录日志
 }

 protected void cleanUp() { /* 默认清理 */ }
}

注意几个关键设计决策：

apply() 声明为 final：防止子类覆盖流程。流程是"不变的骨架"，不应该被篡改。
doApply() 声明为 protected abstract：子类只能实现这个方法。protected 确保只有子类能看到它，外部调用方不会直接调用。
通用方法提供默认实现：validateRequest、postProcess 等方法提供了钩子（Hook），子类可以按需覆盖，但不是必须的。

第三步：子类只写核心逻辑

public class OrderService extends AbstractBusinessTemplate {

 @Override
 protected Result doApply(Request request) {
 // 只需要关注核心业务逻辑
 Order order = createOrder(request);
 orderRepository.save(order);
 return Result.success(order);
 }
}

public class PaymentService extends AbstractBusinessTemplate {

 @Override
 protected Result doApply(Request request) {
 // 每个子类只写自己的核心逻辑
 Payment payment = processPayment(request);
 paymentGateway.charge(payment);
 return Result.success(payment);
 }
}

对比重构前后：原来每个 Service 要写 15-20 行流程代码，现在只需要 3-5 行核心逻辑。

调用方式

调用方完全面向接口编程，不知道也不需要知道模板的存在：

BusinessService service = new OrderService();
Result result = service.apply(request);

📦 实战：数据导出服务

上一节讲了模式的骨架，现在来看一个后端开发中常见的真实场景——数据导出。

假设系统需要支持多种格式的数据导出：CSV、Excel、PDF。不管导出哪种格式，流程都是一样的：

查询数据 → 生成文件 → 上传到存储 → 发送通知

唯一不同的是"生成文件"这一步。这正好是"接口 + 抽象模板"模式的用武之地。

第一步：定义领域模型

// 导出请求
public class ExportRequest {
 private String dataType; // 导出数据类型，如 "order"、"user"
 private LocalDate startDate;
 private LocalDate endDate;
 private String operatorId; // 操作人
 // getter / setter 省略
}

// 导出结果
public class ExportResult {
 private String fileUrl; // 文件下载地址
 private String fileName;
 private long file_size; // 文件大小（字节）
 // getter / setter 省略
}

第二步：接口定义导出契约

public interface DataExporter {
 ExportResult export(ExportRequest request);
}

第三步：抽象模板封装导出流程

public abstract class AbstractDataExporter implements DataExporter {

 @Override
 public final ExportResult export(ExportRequest request) {
 // 1. 参数校验
 validateRequest(request);

 // 2. 查询数据
 List<Map<String, Object>> data = queryData(request);

 // 3. 生成文件（由子类实现）
 byte[] fileContent = generateFile(data);
 String fileName = buildFileName(request);

 // 4. 上传文件
 String fileUrl = uploadFile(fileName, fileContent);

 // 5. 发送通知
 notifyOperator(request.getOperatorId(), fileUrl);

 // 6. 构造结果
 ExportResult result = new ExportResult();
 result.setFileUrl(fileUrl);
 result.setFileName(fileName);
 result.setFileSize(fileContent.length);
 return result;
 }

 // 子类必须实现：按特定格式生成文件
 protected abstract byte[] generateFile(List<Map<String, Object>> data);

 // 子类必须实现：声明文件格式后缀
 protected abstract String getFileExtension();

 // 通用校验逻辑
 protected void validateRequest(ExportRequest request) {
 if (request.getStartDate() == null || request.getEndDate() == null) {
 throw new IllegalArgumentException("导出时间范围不能为空");
 }
 if (request.getStartDate().isAfter(request.getEndDate())) {
 throw new IllegalArgumentException("开始时间不能晚于结束时间");
 }
 }

 // 通用数据查询（实际项目中注入 Repository）
 protected List<Map<String, Object>> queryData(ExportRequest request) {
 // 根据 request.getDataType() 和时间范围查询数据
 return dataRepository.queryByDateRange(
 request.getDataType(),
 request.getStartDate(),
 request.getEndDate()
 );
 }

 // 通用文件上传
 private String uploadFile(String fileName, byte[] content) {
 return storageService.upload(fileName, content);
 }

 // 通用通知
 private void notifyOperator(String operatorId, String fileUrl) {
 notificationService.send(operatorId, "导出完成：" + fileUrl);
 }

 // 构建文件名
 private String buildFileName(ExportRequest request) {
 return request.getDataType() + "_"
 + request.getStartDate() + "_"
 + request.getEndDate()
 + "." + getFileExtension();
 }
}

第四步：具体子类只写文件生成逻辑

// CSV 导出
public class CsvDataExporter extends AbstractDataExporter {

 @Override
 protected byte[] generateFile(List<Map<String, Object>> data) {
 StringBuilder sb = new StringBuilder();

 // 写表头
 if (!data.isEmpty()) {
 String header = String.join(",", data.get(0).keySet());
 sb.append(header).append("\n");
 }

 // 写数据行
 for (Map<String, Object> row : data) {
 String line = row.values().stream()
 .map(v -> String.valueOf(v))
 .collect(Collectors.joining(","));
 sb.append(line).append("\n");
 }

 return sb.toString().getBytes(StandardCharsets.UTF_8);
 }

 @Override
 protected String getFileExtension() {
 return "csv";
 }
}

// Excel 导出（假设使用 Apache POI）
public class ExcelDataExporter extends AbstractDataExporter {

 @Override
 protected byte[] generateFile(List<Map<String, Object>> data) {
 try (Workbook workbook = new XSSFWorkbook()) {
 Sheet sheet = workbook.createSheet("数据导出");

 // 写表头
 Row headerRow = sheet.createRow(0);
 if (!data.isEmpty()) {
 int col = 0;
 for (String key : data.get(0).keySet()) {
 headerRow.createCell(col++).setCellValue(key);
 }
 }

 // 写数据行
 int rowIdx = 1;
 for (Map<String, Object> rowData : data) {
 Row row = sheet.createRow(rowIdx++);
 int col = 0;
 for (Object value : rowData.values()) {
 row.createCell(col++).setCellValue(String.valueOf(value));
 }
 }

 ByteArrayOutputStream out = new ByteArrayOutputStream();
 workbook.write(out);
 return out.toByteArray();
 } catch (IOException e) {
 throw new RuntimeException("Excel 生成失败", e);
 }
 }

 @Override
 protected String getFileExtension() {
 return "xlsx";
 }
}

调用方式与扩展

// 根据用户选择的格式，创建对应的导出器
DataExporter exporter = exporterFactory.getExporter("csv");
ExportResult result = exporter.export(request);
// result.getFileUrl() → "https://storage.example.com/order_2026-01-01_2026-03-31.csv"

如果将来需要支持 PDF 导出，只需新增一个 PdfDataExporter，实现 generateFile() 和 getFileExtension()，其他流程代码一行都不用改。

这正体现了开闭原则：对扩展开放（新增导出格式），对修改关闭（不动已有的导出器和模板）。

从 JdbcTemplate 看真实框架的应用

Spring 的 JdbcTemplate 并没有严格使用继承式模板方法，而是用回调接口实现了同样的思想。理解它有助于你看到这个模式的另一种变体。

JdbcTemplate 的"接口 + 模板"结构

// 1. 回调接口 —— 相当于 doApply()
interface StatementCallback<T> {
 T doInStatement(Statement stmt) throws SQLException;
}

StatementCallback 就是那个"可变的部分"，用户通过实现它来提供具体的 SQL 操作逻辑。

// 2. 模板类 —— 相当于 apply() 的流程控制
public class JdbcTemplate {

 public <T> T execute(StatementCallback<T> action) throws DataAccessException {
 Connection con = DataSourceUtils.getConnection(obtainDataSource());
 Statement stmt = null;
 try {
 stmt = con.createStatement();
 // 调用用户提供的具体逻辑
 T result = action.doInStatement(stmt);
 return result;
 } catch (SQLException ex) {
 // 统一异常转换
 throw translateException("StatementCallback", getSql(action), ex);
 } finally {
 // 统一资源清理
 JdbcUtils.closeStatement(stmt);
 DataSourceUtils.releaseConnection(con, getDataSource());
 }
 }
}

注意 execute() 方法里的流程：获取连接 → 创建 Statement → 执行回调 → 异常处理 → 资源清理。这和我们的 apply() 流程如出一辙。

// 3. 用户代码 —— 只关注 SQL 操作本身
jdbcTemplate.execute(new StatementCallback<Integer>() {
 @Override
 public Integer doInStatement(Statement stmt) throws SQLException {
 stmt.execute("SELECT COUNT(*) FROM users");
 ResultSet rs = stmt.getResultSet();
 rs.next();
 return rs.getInt(1);
 }
});

两种实现的对比

维度	继承式（AbstractBusinessTemplate）	回调式（JdbcTemplate）
扩展方式	继承抽象类	实现回调接口
灵活性	单继承限制	可组合多个回调
适用场景	业务逻辑有明确的父子关系	一次性操作、策略型逻辑
核心思想	一样：固定流程 + 可变逻辑	一样：固定流程 + 可变逻辑

⚡ 容易踩的坑

忘记把 apply() 声明为 final：子类可能不小心覆盖了流程，导致通用逻辑被跳过。如果你使用继承式实现，务必加 final。
在 doApply() 中写流程控制代码：doApply() 应该只包含纯业务逻辑。如果你发现自己在这里做参数校验或资源清理，说明抽象模板的流程设计有问题。
通用方法过度设计：不需要一开始就抽出 10 个 Hook 方法。先写 2-3 个最常用的，等有实际需求时再扩展。

✅ 总结

“接口 + 抽象模板"组合模式的核心思想是分离不变和可变：

不变的部分（流程控制）放在抽象类的 final 方法里
可变的部分（业务逻辑）交给子类的 doApply() 实现
契约（对外暴露什么）由接口定义

这个模式在框架设计中非常常见。无论是 Spring 的 JdbcTemplate、TransactionTemplate，还是业务系统中的订单处理、审批流程，只要存在"相同流程、不同业务"的场景，都可以用这个思想来消除重复代码。

下次你发现自己在多个 Service 中写着相似的 try-catch-finally 结构时，不妨试试这个模式——通用流程放在抽象模板类，让子类只写核心逻辑。

重构实战：打破依赖关系的两种核心方法

Tue, 24 Mar 2026 10:00:00 +0800

一、🎯 背景 & 问题：你的代码为什么难以测试？

在日常开发中，我们经常会遇到这样的困境：

你想给一个 checkout 方法写单元测试，但发现它内部调用了数据库；你想测试 registerUser 方法，但发现它会真的发送邮件…

这些问题的共同特征是：测试依赖外部系统（数据库、网络、第三方服务），导致：

问题	表现
测试运行慢	每次都要连接真实数据库/网络
测试结果不稳定	外部系统的状态不可控
无法独立测试核心逻辑	被副作用绑架

⚠️ 本质原因：代码"设计耦合严重"——业务逻辑与副作用混在一起，形成了难以分割的依赖关系。

本文目标：通过两种实用的重构方法，让你的代码从"依赖具体实现"转变为"依赖抽象 + 可替换实现"，从而获得可独立测试的纯业务逻辑。

💡 读完本文，你将学到：两种常用的变更代码思路（如何解耦）

二、🧩 方案概述：解耦的核心思想

打破依赖关系的本质是 解耦（Decoupling）。

简单来说，就是让代码从：

调用方 --> 直接依赖具体实现

变成：

调用方 --> 依赖抽象接口 --> 可替换的具体实现（真实/测试）

本文介绍两种核心方法：

方法	核心思想	适用场景
🔧 方法拆分	将纯业务逻辑与副作用操作分离	单方法内部混杂多种职责
🔄 依赖倒置	通过接口抽象依赖，引入中介层	类与类之间的强耦合

三、🛠️ 实现步骤

🔧 方法1：方法拆分（逻辑隔离）

核心概念：

📌 纯业务逻辑：可直接测试的计算、校验等（无副作用）
🌊 副作用操作：依赖外部系统的操作（数据库、网络、I/O）

重构目标：将大方法中的"纯业务逻辑"和"副作用操作"拆分，让核心逻辑可单独测试。

原始代码：测试被数据库绑架

public class OrderService {

 public int checkout(Order order) {
 // ① 业务逻辑：计算价格
 int total = 0;
 for (Item item : order.getItems()) {
 total += item.getPrice();
 }

 // ② 副作用：访问数据库（不可控）
 Database db = new Database();
 db.save(order);

 return total;
 }
}

问题：想测试"价格计算"，必须先连接数据库。

重构后：职责分离

public class OrderService {

 public int checkout(Order order) {
 // 1️⃣ 只负责流程编排（orchestration）
 int total = calculateTotal(order);
 save(order);
 return total;
 }

 /**
 * 纯函数：无副作用，可单独测试
 * 通过提炼方法将纯逻辑分离出来
 */
 int calculateTotal(Order order) {
 int total = 0;
 for (Item item : order.getItems()) {
 total += item.getPrice();
 }
 return total;
 }

 /**
 * 副作用方法：隔离数据库依赖
 * 将副作用集中到单独方法中
 */
 private void save(Order order) {
 new Database().save(order);
 }
}

单元测试：无需数据库

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class OrderServiceTest {

 @Test
 void testCalculateTotal() {
 // 准备测试数据
 Order order = new Order(List.of(
 new Item(10),
 new Item(20)
 ));

 // 执行测试 - 不依赖数据库
 int result = new OrderService().calculateTotal(order);

 // 验证结果
 assertEquals(30, result);
 }
}

关键收益：calculateTotal 现在是一个纯函数（Pure Function）——给定相同输入永远返回相同输出，且没有副作用，非常容易测试。

⭐ 测试优势：无需任何 Mock 框架，直接调用即可验证

🔄 方法2：引入中介（依赖倒置）

当依赖关系跨越类边界时，方法拆分就不够用了。这时需要引入一个**中介（接口）**来替代具体实现，让依赖"可替换"。

这就是 依赖倒置原则（Dependency Inversion Principle） 的实践：

📌 高层模块不应依赖低层模块，两者都应依赖抽象
📌 抽象不应依赖细节，细节应依赖抽象

原始代码：硬编码依赖

public class UserService {
 // ❌ 硬编码依赖具体实现（强耦合）
 private RealEmailSender emailSender = new RealEmailSender();

 public void registerUser(String email) {
 // ... 业务逻辑：验证邮箱格式、检查重复等 ...

 // ❌ 副作用：真实发送邮件
 emailSender.sendWelcomeEmail(email);
 }
}

测试困境：测试 registerUser 时会真的发送邮件，既慢又有副作用。

重构步骤

Step 1：定义抽象（接口）

/**
 * 抽象：定义"发送邮件"的能力，而不是具体实现
 */
interface EmailProvider {
 void send(String to, String subject, String content);
}

Step 2：提供真实实现（生产环境使用）

/**
 * 真实实现：生产环境发送真实邮件
 */
class RealEmailSender implements EmailProvider {

 @Override
 public void send(String to, String subject, String content) {
 // 实际发送邮件（网络请求）
 // 调用邮件服务商 API 等
 }
}

Step 3：业务类依赖抽象

public class UserService {

 // ✅ 依赖抽象（接口）而不是具体类
 private final EmailProvider emailProvider;

 /**
 * 通过构造函数注入依赖（Dependency Injection）
 * 调用方决定使用哪个实现
 */
 public UserService(EmailProvider emailProvider) {
 this.emailProvider = emailProvider;
 }

 public void registerUser(String email) {
 // ... 业务逻辑 ...

 // ✅ 调用抽象，不关心具体如何发送
 emailProvider.send(email, "欢迎注册", "欢迎加入我们！");
 }
}

Step 4：创建测试用的 Fake / Stub 实现

/**
 * 测试用实现：只记录调用，不执行真实操作
 */
class FakeEmailSender implements EmailProvider {

 // 记录发送的邮件，用于验证
 private final List<EmailRecord> sentEmails = new ArrayList<>();
 private boolean isCalled = false;

 @Override
 public void send(String to, String subject, String content) {
 // ✅ 不做真实操作，只记录
 sentEmails.add(new EmailRecord(to, subject, content));
 isCalled = true;
 }

 public boolean wasEmailSentTo(String email) {
 return sentEmails.stream()
 .anyMatch(e -> e.to().equals(email));
 }

 // 记录类
 record EmailRecord(String to, String subject, String content) {}
}

单元测试：完全隔离外部依赖

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class UserServiceTest {

 @Test
 void registerUser_shouldSendWelcomeEmail() {
 // 1️⃣ 创建测试替身（Test Double）
 FakeEmailSender fakeEmailSender = new FakeEmailSender();

 // 2️⃣ 注入测试替身
 UserService userService = new UserService(fakeEmailSender);

 // 3️⃣ 执行被测方法
 userService.registerUser("user@example.com");

 // 4️⃣ 验证行为（而不是结果）
 assertTrue(fakeEmailSender.wasEmailSentTo("user@example.com"));
 }
}

关键收益：

🚀 测试速度快：没有网络请求
✅ 测试可重复：结果不受外部服务状态影响
🔍 验证行为：可以精确验证 EmailProvider.send() 是否被调用

四、💡 实战示例 & 踩坑指南

综合案例：订单处理服务

让我们看一个更复杂的例子，结合两种方法：

/**
 * 重构后的订单处理服务：完全可测试
 */
public class OrderProcessor {

 private final PaymentGateway paymentGateway;
 private final InventoryService inventoryService;

 // 通过构造函数注入所有外部依赖
 public OrderProcessor(PaymentGateway paymentGateway,
 InventoryService inventoryService) {
 this.paymentGateway = paymentGateway;
 this.inventoryService = inventoryService;
 }

 public OrderResult process(Order order) {
 // 1️⃣ 纯业务逻辑：验证订单
 validateOrder(order);

 // 2️⃣ 纯业务逻辑：计算总价
 BigDecimal total = calculateTotal(order);

 // 3️⃣ 副作用：检查库存（通过抽象）
 if (!inventoryService.isAvailable(order)) {
 return OrderResult.outOfStock();
 }

 // 4️⃣ 副作用：处理支付（通过抽象）
 PaymentResult payment = paymentGateway.charge(order.getCustomerId(), total);

 // 5️⃣ 纯业务逻辑：根据支付结果处理
 return buildResult(order, payment);
 }

 // 可独立测试的纯方法
 void validateOrder(Order order) {
 if (order == null || order.getItems().isEmpty()) {
 throw new IllegalArgumentException("订单无效");
 }
 }

 // 可独立测试的纯方法
 BigDecimal calculateTotal(Order order) {
 return order.getItems().stream()
 .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))
 .reduce(BigDecimal.ZERO, BigDecimal::add);
 }

 // 可独立测试的纯方法
 private OrderResult buildResult(Order order, PaymentResult payment) {
 return payment.isSuccess()
 ? OrderResult.success(order.getId())
 : OrderResult.paymentFailed(payment.getErrorMessage());
 }
}

常见陷阱 & 解决方案

⚠️ 陷阱	表现	✅ 解决方案
接口过大	一个接口包含十几个方法，实现困难	遵循接口隔离原则，拆分为小接口
过度设计	简单场景也强行引入接口	先有测试需求再抽象，避免过早优化
Mock 滥用	测试全是 Mock，失去实际意义	优先用 Fake，核心业务逻辑用真对象
依赖隐藏	在方法内部 `new` 依赖对象	所有依赖通过构造函数注入

测试策略选择

┌─────────────────────────────────────────────────────────┐
│ 纯业务逻辑（calculateTotal, validateOrder） │
│ └── 直接测试，无需任何 Mock/Fake │
├─────────────────────────────────────────────────────────┤
│ 外部依赖（EmailProvider, PaymentGateway） │
│ ├── 集成测试：使用真实实现（连接测试环境） │
│ └── 单元测试：使用 Fake/Stub 实现 │
├─────────────────────────────────────────────────────────┤
│ 协调/编排逻辑（checkout, process） │
│ └── 使用 Fake 验证交互行为 │
└─────────────────────────────────────────────────────────┘

五、📋 总结

核心要点回顾

为什么要打破依赖：让代码可测试、可维护，将业务逻辑与副作用分离

两种核心方法：

🔧 方法拆分：在同一类内分离纯逻辑与副作用
🔄 引入中介：通过接口实现类间的依赖倒置

关键原则：

依赖抽象，而非具体实现
构造函数注入依赖
优先使用可独立测试的纯函数

重构决策流程

开始
 │
 ▼
方法内部混杂了业务逻辑和副作用？ ──是──▶ 方法拆分（提炼纯函数）
 │否
 ▼
类依赖了具体实现导致难以测试？ ────是──▶ 引入中介（依赖倒置）
 │否
 ▼
结束（代码已足够清晰）

💡 实践建议：下次写代码时，先问自己——“这个方法能脱离数据库运行测试吗？“如果不能，也许就是重构的时候了。

六、📚 参考

程序员的README (豆瓣) - 第二章的部分内容

ConcurrentHashMap 原理分析

Mon, 16 Mar 2026 11:05:04 +0800

概述

ConcurrentHashMap 是 Java 并发包中最重要的并发容器之一，本文将深入分析其实现原理。

核心特点

线程安全：无需额外同步措施即可在多线程环境下使用
高性能：采用分段锁/ CAS 机制，减少锁竞争
弱一致性：迭代器不保证强一致性，但不会抛出 ConcurrentModificationException

JDK 1.7 实现：分段锁

Segment 结构

static final class Segment<K,V> extends ReentrantLock {
 transient volatile HashEntry<K,V>[] table;
 // ...
}