Google Cloud Spanner空提交触发AbortedException问题排查求助

我正在使用Google Cloud Spanner开发Java程序，采用多线程方式在手动事务中执行批量插入操作：每个线程独立生成并维护自身的mutation数组，过程中会向本地数组添加插入mutation，同时执行空提交。目前遇到的问题是：AbortedException仅在空提交时触发，达到批量提交阈值执行提交时反而不会出现。事务通过TransactionManager和TransactionContext管理，需要排查该异常仅在空提交时发生的原因。

程序核心逻辑 #

应用在SpannerClient类中实现批量处理逻辑：每个线程创建插入mutation并存储在bufferedMutations（ArrayList<Mutation>）中，累积至设定的批量大小后，通过单事务提交至Google Cloud Spanner。

触发的两类错误信息 #

---------------------------------------------------------------------------------------------------------------
Thread-138 in SpannerClient.commit() method- AbortedException occurred.
Current size of mutation buffers array: 94.
Stack Trace:com.google.cloud.spanner.AbortedException: ABORTED: io.grpc.StatusRuntimeException: ABORTED: Database schema has changed



---------------------------------------------------------------------------------------------------------------
Thread-0 in SpannerClient.commit() method- AbortedException occurred.
Current size of mutation buffers array: 77.
Stack Trace:com.google.cloud.spanner.AbortedException: ABORTED: io.grpc.StatusRuntimeException: ABORTED: Transaction was aborted.
retry_delay {
  nanos: 38655229
}

异常仅在空提交时触发的原因分析 #

• 空提交的事务校验逻辑特性
  空提交（无mutation的提交）不会产生实际数据写入，Spanner对这类事务仅执行基础状态校验：包括事务是否仍处于有效状态、数据库schema是否发生变更等，不会触发写入阶段的冲突处理流程。当schema变更或事务被标记为终止时，空提交会直接抛出AbortedException；而带写入的提交会进入完整的写入流程，其内部的冲突处理、状态校验逻辑会和空提交不同，可能提前规避或自动处理这类异常。

• 事务生命周期与心跳机制差异
  Spanner手动事务存在生命周期限制，若事务长时间无操作（写入或提交）会被标记为过期。空提交本质是事务的"心跳"操作，但如果事务已因schema变更或超时被标记为不可用，空提交的校验会直接触发异常；而带写入的提交在执行前的有效性检查环节，会触发客户端的重试逻辑，自动重新开启事务执行写入，不会将异常暴露到应用层。

• schema变更的影响时机
  当数据库schema变更时，Spanner会终止所有未完成的事务。空提交作为事务的即时操作，会立刻检测到事务失效状态并抛出异常；而带写入的提交会被Spanner内部机制拦截，自动重试并创建新事务执行写入，因此不会将AbortedException抛给应用。

• 客户端重试策略差异
  批量提交包含实际写入操作，Spanner Java客户端默认重试策略会针对写入型操作处理AbortedException并自动重试事务；而空提交属于无写入操作，客户端未启用对应重试逻辑，导致异常直接暴露。

内容的提问来源于stack exchange，提问作者kentoto