V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
22yune
V2EX  ›  Java

Java 线程池核心线程数自适应算法 探讨

  •  
  •   22yune · 2021-10-20 17:50:24 +08:00 · 2541 次点击
    这是一个创建于 891 天前的主题,其中的信息可能已经有所发展或是发生改变。
    场景:在指定时间内尽量请求多个服务的数据。使用线程池并发请求数据。

    问题:核心线程数设置小了要等队列满了才加线程,队列小了缓冲不够大,队列大了,加线程要等太久;
    核心线程数设置大了,可能太浪费,设置核心线程超时,设置大了也会导致前面的线程应超时销毁,后面的请求又一直创建线程。

    解决思路:核心线程数开始设置最大线程数的一半,设置监测点:在核心线程超时销毁时,减小一半核心线程数,在队列达到现有线程数处理能力设定负载量时,增长一定比例核心线程数。核心线程数不能超过最大线程数。

    大家觉得怎么样?
    17 条回复    2021-11-03 01:22:19 +08:00
    guaguaguaxia1
        1
    guaguaguaxia1  
       2021-10-20 17:54:55 +08:00
    美团技术团队的方法是把线程数做成可配置的,有问题后台改一下配置就好了
    dqzcwxb
        2
    dqzcwxb  
       2021-10-20 18:17:53 +08:00
    https://v2ex.com/t/741974
    没有算法,业务压测自己配
    22yune
        3
    22yune  
    OP
       2021-10-20 19:54:27 +08:00
    @guaguaguaxia1 这个是配合监控,人工计算再配置吧。我说的自适应算法是把这个过程程序化自动化。
    SoloCompany
        4
    SoloCompany  
       2021-10-20 20:37:52 +08:00
    用 SynchronousQueue 加一个备用队列, task reject 时才加入到备用队列
    chihiro2014
        5
    chihiro2014  
       2021-10-20 23:28:33 +08:00
    可以看看 Project Reactor 中 Scheduler 的设计方式??和你说的类似
    546L5LiK6ZOt
        6
    546L5LiK6ZOt  
       2021-10-21 00:23:20 +08:00 via iPhone
    既然核心线程数可以增加,为啥不一开始就配置跟最大线程数一样呢?核心线程数也可以设置空闲时间,晚一点销毁感觉对性能影响不大。感觉楼主提的方案对性能提升不大,当然还是实际测试下好。

    线程池本质就是复用资源,资源有限。所以我觉得理想的自适应做法应该是想办法自动判断资源数量。例如说数据库连接池,你得想办法用程序来判断多少连接才是最好的。
    nl101531
        7
    nl101531  
       2021-10-21 09:21:27 +08:00 via iPhone
    因为有销毁机制,所以一般设置大一点没多大问题。不过在有些具备流量峰值的系统就挺有用的了,应对峰值可以迅速自动调整策略。这个可以作为一个通用能力。
    GrayXu
        8
    GrayXu  
       2021-10-21 09:30:49 +08:00
    @546L5LiK6ZOt elasticity
    546L5LiK6ZOt
        9
    546L5LiK6ZOt  
       2021-10-21 10:31:02 +08:00 via iPhone
    我想到的一个方法是,监控 cpu 、内存利用率等系统指标。如果负载低,则增加线程数量。
    lidlesseye11
        10
    lidlesseye11  
       2021-10-21 10:34:56 +08:00
    notwaste
        11
    notwaste  
       2021-10-21 16:14:15 +08:00
    美团有给出可配置的方案,我比较关注拒绝策略的场景选择
    mawerss1
        12
    mawerss1  
       2021-10-21 23:13:28 +08:00 via iPhone
    本质还是和任务的执行时长有关,线程数太高 cpu 占用上升,线程切换时间占用变高浪费 cpu 时间,线程数太低任务堆积最终响应时间变长,追求高响应应该直接拒绝执行报错,还是压测加机器
    22yune
        13
    22yune  
    OP
       2021-10-23 15:49:56 +08:00
    @546L5LiK6ZOt 设置大了也会导致前面的线程应超时销毁,后面的请求又一直创建线程。这样的结果就是线程池基本没有用,线程一直在创建新的。
    @nl101531 是的 大一点没有问题,但也只能稍微改善一点点,当流量大了后还是回到 要等待队列满还是小队列 快速拒绝的选择。
    @lidlesseye11 是的,这可能是更简单健壮的算法:按队列增长比例增长核心数到最大数。
    @mawerss1 直接拒绝执行就是设置小队列策略了。我现在就用这个设置。觉得还有点不够尽善尽美,没有用上队列的缓冲能力。一些小流量波动或网络波动或下游服务响应慢一点就会产生大量报警,这个时候并不需要加机器。
    mawerss1
        14
    mawerss1  
       2021-10-23 16:48:54 +08:00
    @22yune 设置一个在队列中的等待时间?超时了就放弃
    22yune
        15
    22yune  
    OP
       2021-10-23 18:07:58 +08:00
    @mawerss1 比如聚合接口最大响应时间 3 秒,正常响应时间 90%以上是 500ms 以下。假设最大线程数能到 1000 。那请求在队列中等待 2.5 秒是很可能会正常响应的。2.5 秒可以执行完成 5 个批次,队列可以缓存 5 * 1000 个请求,再大的队列就没用了。但初始核心线程可能是 100 。在队列满之后要等 25 才能消费完,这就是因线程增长太慢导致的。如果线程能随着队列排队增长而增长,则加入队列的都是可能正常响应的。在流量达到真正的负载上线时都不会失败。
    zeni123
        16
    zeni123  
       2021-11-03 00:59:44 +08:00 via iPhone
    当有多个机器的时候 线程池的设置可以有多套 profile

    profile 1 20-40
    profile 2 1000-2000
    profile 3 100-100

    …..

    就类似于 cpu 大小核心那样
    zeni123
        17
    zeni123  
       2021-11-03 01:22:19 +08:00
    线程池的参数要根据具体任务类型而配置

    当有多个机器的时候 线程池的设置可以有多套 profile

    例如你有 50 台一样的机器

    a 台设置成 Core 10 MAX 100
    b 台设置成 Core 10 MAX 20
    c 台设置成 Core 10 MAX 10
    d 台设置成 Core 200 MAX 400
    e 台设置成 Core 200 MAX 200


    然后 a+b+c+d + e=50

    随机给任务 ,统计任务的 throughput/响应

    然后动态调节 a,b,c,d,e 的值使得 50 台机器总的 throughput/响应 最优
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2867 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 13:10 · PVG 21:10 · LAX 06:10 · JFK 09:10
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.