因为 Dubbo 线程池总数默认是固定的,200 个,假设系统在单位时间内可以处理 500 个请
求,一旦 queryOrderById 的请求流量上来了,极端情况下,可能会出现 200 个线程都在处
理这个耗时的任务,那么剩下的 300 个请求,即使是不耗时的功能,也很难有机会拿到线程
资源。所以,紧接着就导致 Dubbo 线程池耗尽了。 可采用业务异步化处理操作:
核心实现就 3 点:
-
定义线程池对象,通过 RpcContext.startAsync 方法开启异步模式;
-
在异步线程中通过 asyncContext.signalContextSwitch 同步父线程的上下文信息;
-
在异步线程中将异步结果通过 asyncContext.write 写入到异步线程的上下文信息中。
//创建线程池对象
ExecutorService cachedThreadPool = Executors.newCachedThreadPool();
//开启异步
AsyncContext asyncContext = RpcContext.startAsync();
cachedThreadPool.execute(() -> {
asyncContext.write("返回结果:" + name);
});
return null;