Java使用web3j监听区块链事件触发LogFilter空指针异常该如何解决

问题根因 #

该空指针异常出现在web3j内置的LogFilter日志过滤器处理逻辑中，触发场景通常是节点返回的日志结果不符合预期（包含空值/异常类型结果）、查询区块范围过大导致节点返回异常结果，或是对应版本web3j未对返回结果做非空校验。

可行解决办法 #

1. 重写LogFilter类临时修复 #

利用JVM类加载优先级，在项目中创建和官方完全一致的包路径org.web3j.protocol.core.filters，自定义LogFilter类，在原有逻辑上补充非空校验即可：

@Override
protected void process(List<EthLog.LogResult> logResults) {
    // 先判断集合非空
    if (logResults == null || logResults.isEmpty()) {
        return;
    }
    for (EthLog.LogResult logResult : logResults) {
        // 单条结果非空校验
        if (logResult == null) {
            continue;
        }
        if (logResult instanceof EthLog.LogObject) {
            Log log = ((EthLog.LogObject) logResult).get();
            // 校验解析后的Log非空再回调
            if (log != null) {
                callback.onEvent(log);
            }
        } else {
            throw new FilterException(
                    "Unexpected result type: " + logResult.get() + " required LogObject");
        }
    }
}

优点：改造成本极低，不影响原有业务代码逻辑，直接修复空指针问题。
缺点：属于临时补丁，后续升级web3j版本时需要同步确认官方是否已经修复该问题。

2. 弃用内置过滤器流，改用主动分段拉取日志 #

避开有问题的ethLogFlowable内置过滤器实现，自己实现定时任务按区块范围主动调用ethGetLogs接口拉取日志：

// 示例伪代码
private BigInteger currentBlockHeight = new BigInteger("7605105");
// 每次最多拉取2000个区块的日志，可根据节点配置调整
private static final BigInteger STEP = new BigInteger("2000");

// 定时任务每10秒执行一次
@Scheduled(fixedDelay = 10000)
public void pullLogs() {
    try {
        BigInteger latestBlock = web3j.ethBlockNumber().send().getBlockNumber();
        if (currentBlockHeight.compareTo(latestBlock) > 0) {
            return;
        }
        BigInteger endBlock = currentBlockHeight.add(STEP).min(latestBlock);
        EthFilter filter = new EthFilter(
                DefaultBlockParameter.valueOf(currentBlockHeight),
                DefaultBlockParameter.valueOf(endBlock),
                contractAddress
        );
        EthLog ethLog = web3j.ethGetLogs(filter).send();
        List<EthLog.LogResult> logs = ethLog.getLogs();
        // 自己处理日志逻辑
        processLogs(logs);
        // 更新拉取进度
        currentBlockHeight = endBlock.add(BigInteger.ONE);
    } catch (Exception e) {
        log.error("拉取日志异常", e);
    }
}

优点：稳定性最高，完全绕开web3j内置过滤器的bug，可自定义进度持久化、失败重试逻辑，节点兼容性更好。
缺点：需要额外实现拉取逻辑、进度维护。

3. 补充RxJava流异常重试机制 #

在原有ethLogFlowable流上添加重试操作符，出现异常后自动重新订阅恢复服务：

subscription = web3j
        .ethLogFlowable(filter)
        // 出现异常后延迟1秒重试，无限重试
        .retryWhen(errors -> errors.flatMap(e -> Flowable.timer(1, TimeUnit.SECONDS)))
        .subscribe(
                event -> {
                    // 原有日志处理逻辑
                }, error -> {
                    log.error("Event error: {}", error, error);
                });

优点：改造成本低，不需要修改原有逻辑，避免单次异常导致整个订阅终止。
缺点：属于兜底方案，没有从根本上解决空指针问题，异常触发时会短暂丢失日志，需要配合幂等处理。

4. 调整区块查询范围 #

如果是单次查询区块范围过大导致节点返回异常结果，可适当缩小首次查询的起始区块高度，或是升级web3j到最新版本确认官方是否已经合并修复补丁。

内容的提问来源于stack exchange，提问作者Paul Verest on LinkedIn