响应式应用中java.io.RandomAccessFile.readBytes阻塞调用是否可接受？适用场景有哪些

影响严重程度 #

这类读本地属性文件的阻塞属于非常轻量的阻塞场景：

• 单次阻塞时长极短：读取的properties文件通常只有几KB到几十KB，本地磁盘IO耗时基本在几微秒到几毫秒区间，远低于网络、数据库类阻塞的耗时
• 触发概率极低：hibernate-validator、orika这类库默认都会对加载后的配置、消息资源做全局缓存，阻塞调用只会在类加载后第一次触发相关功能时出现一次，后续所有请求都会直接读内存缓存，不会再触发文件IO
• 仅极端场景会有明显影响：如果你的应用属于核心低延迟业务，且QPS持续过万，刚好在流量高峰时段触发资源初始化，才有可能导致event loop线程短暂阻塞，出现少量请求响应毛刺。普通流量规模的应用基本感知不到这类阻塞的存在。

是否可以忽略？ #

分场景判断：

• 符合以下条件可以直接忽略：
  • 应用对响应时间毛刺容忍度较高，非核心低延迟业务
  • 可以在启动阶段预加载相关资源：比如应用启动时主动触发一次参数校验、orika映射操作，把仅会出现一次的阻塞操作移到启动期，运行期不会再出现BlockHound告警
• 不建议忽略的场景：
  • 应用属于核心交易链路，要求p999响应时间严格达标
  • 应用集群规模大、流量极高，哪怕微秒级的阻塞也可能引发连锁的请求排队

解决方案 #

不需要完全替换现有校验、映射框架，低成本优化方案如下：

• 预加载缓存：自定义hibernate validator的MessageInterpolator，启动时一次性把所有国际化消息资源加载到内存缓存，运行期直接读内存返回，完全避免文件IO
• 调度到弹性线程池执行：把校验、orika映射逻辑用publishOn(Schedulers.boundedElastic())包裹，让阻塞操作运行在专门处理阻塞任务的弹性线程池上，不占用event loop线程
• 替换资源加载逻辑：如果是容器化部署，可以把相关properties文件挂载到tmpfs内存文件系统，读取操作本质就是读内存，不会产生磁盘阻塞

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