业务背景：
现网业务是负责问答内容展现相关，涉及到普通的http请求和大模型流式请求。为了更好的展现问答相关的内容，部分http响应的内容就渲染成一个卡片类型展现，如手机上的询问天气和查询体育赛事等。在普通http接口返回的内容不是很恰当时，会使用大模型的结果进行替代，大模型结果的展示方式为流式蹦字展示。普通http接口和大模型接口是并发调用的，因为不确定哪些query能被某个接口cover住。
在业务调用量比较少的时候功能表现正常，只是可能某些时段某些场景下的query比友商较弱些，但是在可接收范围内。但是随着某个版本的发布，业务调用量上来后，结果展示效果延时增加许多，并且很多http接口能够稳定cover住的场景下，没用展示卡片效果，也展示了流式结果。在收到几个现网告警后，立刻警觉起来，着手分析。
时延增加，首先想到是调用下游接口耗时。查看本服务日志时，发现获取http接口的结果的时候，报了一个底层native方法的错误，猜测是请求下游时出错。但是发现很多请求，在下游机器上并没有搜索到日志，开始还以为是日志采集平台出了问题。后来找到现网运维人员帮忙去云机器上查看时发现机器上也没有日志产生。判断请求可能没有到达下游服务。
请求执行出错，没有到达下游，并且CPU使用率较高，怀疑可能是代码哪边发生了内存泄漏拖慢了进程，决定先重启一个机器试试水。重启后发现，发现问题得到缓解。以为问题就是这样，准备去未重启的机器上拷贝一份dump分析内存了。但是没有开心多久，问题再次出现。为了减小业务影响，紧急扩容几台机器。问题暂时得到控制。
没办法，为了分析根因，只能扒代码一步步正向分析了，但发现代码逻辑并没有什么问题，一切回到了原点。想到请求执行是丢在线程池中运行的，怀疑是线程池的原因。但是发现线程池和其他服务中使用的方式一样，是Java原生的方式如下面方式：
new ThreadPoolExecutor(256, 512,
5, TimeUnit.MINUTES, new ArrayBlockingQueue<>(500), (runnable) ->
{
Thread thread = new Thread(runnable);
thread.setName("XXX");
return thread;
}, new RejectedExecutionHandler());
并且两种请求的线程池使用的同一个。只能再次梳理下业务逻辑，发现问题就出在了这个线程池上面。Java原生的线程池的逻辑是，先创建核心线程处理----> 放入队列 ----> 创建最大线程处理 ----> 对新任务执行拒绝策略。发生告警时也没有出现拒绝策略执行的日志。
对于普通业务场景是没有问题的，这个可以最大的提升服务的吞吐量。但是本服务比较特殊，有普通http接口请求（执行很快）。大模型接口请求（请求允许一定时间的耗时）。这就有问题了，因为他们用的是同一个线程池，大模型请求由于耗时久会占用大部分的工作线程，http接口请求时间短，由于抢占不到线程执行会出现无法在规定的时间内执行完成。这需要服务不能再以吞吐量优先了，需要以响应时间优先。其实之前看Tomcat源码时也看到过这个问题，只是没有想到将其使用到业务中，具体的可以看之前写的文章 Tomcat实现的线程池。其自己实现的线程池逻辑是，先创建核心线程处理----> 创建最大线程处理 ----> 放入队列 ----> 对新任务执行拒绝策略。实现了响应时间优先，并且支持一定的吞吐量。
业务为了简单处理，修改了下线程池的创建方式，改成了下面的方式：
new ThreadPoolExecutor(256, 512,
5, TimeUnit.MINUTES, new SynchronousQueue<>(), (runnable) ->
{
Thread thread = new Thread(runnable);
thread.setName("XXX");
return thread;
} , new RejectedExecutionHandler());
经过这次的现网问题，发现平时写代码还是要多思考业务场景，学习的东西要能够融会贯通，学习到并能会使用才是自己的。
