WebFlux场景下UUID生成阻塞性及反应式实现相关技术问题
以下是针对所有问题的解答：
这段代码是否存在阻塞？是否需要关注该问题？
存在阻塞风险，必须关注。UUID.randomUUID()底层依赖SecureRandom生成随机数，其engineNextBytes方法是同步实现，高并发场景下会产生剧烈的锁竞争导致阻塞。如果服务QPS很低影响不大，但是高并发场景下这个阻塞点会直接拉低服务吞吐量，极端情况会把NIO线程卡死，必须处理。在Reactor中用ThreadLocal封装UUID生成逻辑是否有意义？
基本没有意义。首先UUID.randomUUID()内部默认使用全局单例的SecureRandom，除非你用ThreadLocal为每个线程单独初始化独立的SecureRandom实例，否则单纯封装UUID生成逻辑完全解决不了锁竞争问题。另外Reactor的线程都是池化复用的，ThreadLocal不会自动清理，如果逻辑依赖上下文传递，还要额外处理上下文切换的问题，反而容易引入隐患。写法(A)和写法(B)之间是否存在差异？
默认执行场景下没有本质差异，两者的enhance方法都会在订阅触发时的当前线程执行。唯一的区别是Mono.fromCallable会主动捕获Callable抛出的异常转为错误信号，而Mono.just(o).map()里的map方法抛出的异常也会被Reactor自动捕获转为错误信号，实际运行效果完全一致。只有后续指定了subscribeOn/publishOn调度器的时候才会产生调度差异，但这里两种写法都没有加调度器，运行效果没有区别。为什么其余3个线程没有因为
SecureRandom实例的锁而进入阻塞状态？
因为onBeforeConvert是Spring Data R2DBC的回调接口，默认不会在reactor-http-nio线程执行，而是调度到R2DBC内部的独立线程池执行。你观测到的reactor-http-nio线程只负责处理网络IO，根本没有执行enhance里的UUID生成逻辑，当然不会争抢SecureRandom的锁，自然不会阻塞。那3个NIO线程持有的是NIO选择器的锁，和SecureRandom的锁完全无关。为什么在该场景下线程会阻塞，但放在
onBeforeConvert()中时不会出现阻塞？另外我尝试用ThreadLocal封装调用也没有解决该问题。doOnNext默认在当前触发信号的线程执行，如果你没有指定调度器，就会直接在reactor-http-nio线程执行，多个NIO线程同时执行UUID生成逻辑就会争抢全局SecureRandom的锁，自然会阻塞。而onBeforeConvert的执行线程是R2DBC的独立线程池，和NIO线程完全隔离，所以NIO线程不会被阻塞。
至于ThreadLocal封装无效，大概率是你只是封装了UUID的调用逻辑，没有真正为每个线程初始化独立的SecureRandom实例，线程调用时还是用的全局单例的SecureRandom，当然解决不了锁竞争问题。我原本预期4个线程都会持有自己的
SecureRandom实例，这个认知是否正确？是否只有主线程持有该实例，将任务分发给没有SecureRandom线程本地变量的工作线程执行？
这个认知不正确。默认情况下UUID.randomUUID()使用的是全局共享的单例SecureRandom实例，不管哪个线程调用都是争抢同一个对象的锁，JDK默认不会为每个线程分配独立的SecureRandom实例。只有你手动通过ThreadLocal为每个线程单独初始化SecureRandom，才会实现每个线程持有独立实例的效果。为什么这些线程会进入阻塞状态，而之前方案中的
reactor-http-nio线程不会被阻塞？
你添加subscribeOn(Schedulers.boundedElastic())之后，enhance方法会被调度到boundedElastic线程池执行，这些线程现在要执行UUID生成逻辑，争抢全局SecureRandom的锁，所以会发生阻塞。而之前的reactor-http-nio线程不需要执行enhance逻辑，所有阻塞都发生在专门处理阻塞任务的boundedElastic线程池里，所以NIO线程可以正常处理网络IO不会被阻塞。这种写法其实是合理的，相当于把阻塞逻辑转移到了专属线程池，避免了NIO线程被阻塞影响服务整体的IO处理能力。
内容的提问来源于stack exchange，提问作者Another Dimension
