Callable接口本身不共享数据，其核心作用是定义带返回值、可抛异常的call()方法；真正实现线程间数据共享依赖于多个Callable实例共同操作同一外部对象，并配合synchronized、ReentrantLock、原子类或线程安全容器等同步机制保障线程安全。
Java 中 Callable 接口本身不直接负责共享数据，它只定义了一个带返回值、可抛异常的 call() 方法。真正处理线程间共享数据的，是你如何设计共享变量、选择同步机制、以及如何组织 Callable 实例与执行环境。
关键点在于：Callable 是任务契约，不是数据容器；共享数据靠的是 Java 内存模型 + 同步手段 + 对象生命周期管理。
✅ 共享数据的核心前提：多个 Callable 实例操作同一对象
Callable 通常配合 FutureTask 或线程池使用。若想让多个线程（即多个 Callable 任务）共享数据，必须确保它们引用同一个外部对象——而不是各自持有独立副本。
例如，下面这段代码中，Counter 是共享状态，所有 MyCallable 实例都操作它：
立即学习“Java免费学习笔记（深入）”；
static class Counter {
private int value = 0;
public synchronized void increment() { value++; }
public int getValue() { return value; }
}
static class MyCallable implements Callable<Void> {
private final Counter counter;
public MyCallable(Counter c) { this.counter = c; }
@Override
public Void call() {
counter.increment();
return null;
}
}调用时：
Counter shared = new Counter();
ExecutorService pool = Executors.newFixedThreadPool(4);
List<Future<?>> futures = new ArrayList<>();
for (int i = 0; i < 4; i++) {
futures.add(pool.submit(new MyCallable(shared)));
}
pool.shutdown();
futures.forEach(f -> { try { f.get(); } catch (Exception e) {} });
System.out.println(shared.getValue()); // 输出 4（线程安全）? 线程安全的常见保障方式
共享数据必须防止竞态条件。常用手段包括：
synchronized 方法或代码块
如上例中increment()加了synchronized，保证同一时刻只有一个线程修改value。-
显式锁（ReentrantLock）
更灵活，支持尝试获取、超时、公平性等：private final ReentrantLock lock = new ReentrantLock(); public void increment() { lock.lock(); try { value++; } finally { lock.unlock(); } } -
原子类（AtomicInteger、AtomicReference 等）
适合简单状态更新，无锁且高效：private final AtomicInteger value = new AtomicInteger(0); public void increment() { value.incrementAndGet(); } 线程安全容器（ConcurrentHashMap、CopyOnWriteArrayList）
当共享的是集合类型时优先选用，避免手动同步。
⚠️ 注意：仅把变量声明为 static 或 final 并不能保证线程安全——static 只是共享范围广，但读写仍需同步；final 只保证引用不可变，不保证其指向对象的内部状态线程安全。
❌ 常见误区：每个 Callable 自带一份数据
以下写法无法共享，因为每个 MyCallable 都有自己独立的 count：
class BadCallable implements Callable<Integer> {
private int count = 0; // 每个实例私有！
@Override
public Integer call() {
count++; // 修改的是自己的副本
return count;
}
}即使提交给同一个线程池，结果仍是 4 个 1，而非累计到 4。
? Callable + 共享数据的典型协作模式
| 场景 | 推荐做法 |
|---|---|
| 多个任务协同更新一个计数器/累加器 | 将共享对象（如 AtomicInteger 或带锁的 Counter）作为参数传入每个 Callable 构造器 |
| 任务需要读写同一份配置或缓存 | 使用 ConcurrentHashMap 存储，或封装成单例服务类，由 Callable 调用其线程安全方法 |
| 不同任务修改不同字段，但属于同一业务实体 | 把该实体作为共享对象，各 Callable 调用其不同同步方法（如 updatePrice() / updateStock()） |
| 需要最终聚合结果（如分段计算后汇总） | 各 Callable 返回局部结果（Future<T>），主线程用 get() 收集后再合并，避免共享写冲突 |
? 补充：为什么不用 Runnable？什么时候必须用 Callable？
-
Runnable适合“只执行、不反馈”的场景（如日志记录、定时清理）； -
Callable适合需要返回结果 + 异常传播 + 任务取消的场景（如远程调用、数值计算、资源预加载）； - 若共享数据还需被主线程后续使用（比如统计总耗时、汇总结果），
Callable的Future.get()天然支持阻塞等待+结果提取，比手动维护共享变量更清晰可靠。
不复杂但容易忽略：共享数据的关键不在接口选型，而在对象是否真被多个线程共用，以及访问路径是否受控同步。Callable 只是让这个过程更可控、更可追踪。
