同步执行阻塞源于线程等待资源时被挂起且调用栈滞留，预防关键在于从源头控制同步范围、时长与依赖：精简临界区、移出非共享操作、禁i/o与睡眠、设锁超时、统一多锁顺序、以异步替代同步等待，并主动监控阻塞点。

同步执行导致的阻塞，本质是线程在等待资源（如锁、I/O、数据库响应）时被挂起，而调用栈持续增长或长时间停留在临界区，容易引发级联延迟、线程耗尽甚至服务雪崩。预防的关键不在于“监控调用栈深度”本身，而在于**从源头控制同步行为的范围、时长与依赖关系**。

限制同步临界区的粒度和时长

过长的同步块会放大阻塞风险——哪怕只是一段日志记录或简单计算，若裹在锁内，也会拖慢所有等待线程。

• 只对真正需要互斥访问的共享状态加锁，把非共享操作（如参数校验、本地变量计算、JSON序列化）移出 synchronized 块或 Lock 作用域
• 避免在同步块内做 I/O（文件读写、HTTP 调用、数据库查询）、睡眠（Thread.sleep）、或调用未知行为的第三方方法
• 为锁操作设置超时：ReentrantLock.tryLock(timeout, unit) 比无条件 lock() 更安全，失败后可降级或重试，而非无限等待

统一锁获取顺序，切断死锁链

多个资源同时加锁时，顺序混乱是死锁的直接诱因；而死锁会让调用栈卡在 wait() 或 park() 状态，深度不变但线程永久阻塞。

百度AI开放平台

百度AI开放平台是一款提供语音、图像、自然语言处理和行业 AI 能力的技术开放平台。

下载

• 对所有需多锁操作的对象，定义全局唯一排序依据（如 Account.id 的自然序、对象 hashCode() 的绝对值、或预分配的 long 序号）
• 每次按升序（或降序）依次尝试获取锁，确保所有线程遵循同一路径，消除循环等待条件
• 示例：转账前先锁 id 小的账户，再锁 id 大的，无论参数传入顺序如何

用异步/非阻塞替代同步等待

当阻塞不可避免（如远程调用），就该让等待不占用业务线程——把“同步等结果”变成“异步收通知”，释放调用栈上下文。

• 对 HTTP、RPC、DB 查询等 I/O 密集操作，优先使用 CompletableFuture、WebClient、或响应式客户端（如 R2DBC），配合线程池隔离
• 定时任务、消息消费等场景，用 @Async + 自定义线程池，避免挤占 Tomcat 或 Netty 的 I/O 线程
• 前端调用后端接口时，避免服务端同步等待下游响应；改用回调、事件总线或状态轮询机制

主动暴露阻塞点，便于快速定位

调用栈深度本身不是问题，但长期停留在某一层（如 Object.wait、Unsafe.park、SocketInputStream.read）就是明确信号。

• 启用 JVM 线程 dump 定时采集（如每 5 分钟 jstack），结合 APM 工具（如 SkyWalking、Arthas）标记阻塞线程及其锁持有者
• 在关键同步入口打日志，记录进入时间、锁对象标识、预计最大等待时长；超时未退出则告警
• 对数据库操作，开启 slow query 日志 + 锁等待监控（如 MySQL 的 performance_schema.data_locks）