Callable返回null合法，但调用方未判空直接拆箱会触发NullPointerException；应明确契约是否允许null，若允许则调用处必须显式判空或用Optional封装，推荐Callable<Optional<T>>模式。
callable 返回 null 本身合法，但若后续代码将其当作非空泛型类型（如 integer、boolean）直接拆箱（例如 result.intvalue()），就会触发 nullpointerexception。这不是泛型的问题，而是空值未校验 + 自动拆箱共同导致的崩溃。关键在调用方做防御性处理，而非强行禁止 null 返回。
明确 Callable 的契约：是否允许返回 null
先确认业务逻辑中 Callable<T> 的 call() 方法是否本应返回 null（比如查询无结果、计算未就绪）。如果设计上绝不应为 null，就在 call() 内部抛出明确异常（如 IllegalStateException），而不是静默返回 null。若允许 null，则所有调用处必须主动判空。
调用方必须显式判空，避免自动拆箱
获取 Future.get() 结果后，不要直接调用原始类型方法。改用以下方式之一：
- 用
Objects.nonNull(result)或result != null显式检查 - 对包装类型使用
Optional.ofNullable(result)封装后再处理 - 需要基本类型时，提供默认值：
int value = (result != null) ? result : 0; - 避免写
result.toString()、result.hashCode()、result.compareTo(...)等隐式解引用操作
借助 Optional 封装返回值（推荐长期方案）
将 Callable<T> 升级为 Callable<Optional<T>>，让 null 意图更清晰：
Callable<Optional<Integer>> task = () -> {
Integer val = compute();
return Optional.ofNullable(val); // 明确表达“可能无值”
};
Optional<Integer> opt = future.get();
int safeValue = opt.orElse(0); // 安全获取默认值
这样既保留语义，又天然规避了拆箱风险。
统一工具方法兜底（适合存量代码快速修复）
为常用包装类型写安全拆箱工具，例如：
public static int safeUnbox(Integer x, int defaultValue) {
return (x != null) ? x : defaultValue;
}
// 调用：int v = safeUnbox(future.get(), -1);
比处处写三元更简洁，也比 try-catch 更精准。
不复杂但容易忽略：null 是值，不是类型错误；崩溃永远发生在使用端，不在 Callable 定义端。守住调用侧的空值边界，比试图“阻止 null 返回”更实际有效。
