zoukankan      html  css  js  c++  java
  • 线程池灵感记录

    最近在工作中,遇见几次事故多多少少都与线程池有些关系,都是 noAvaliableThradException 等问题。通过分析 CPU load 、 CPU 利用率、memory 使用情况、请求响应时间,来分析寻找rootcase。机器基本都是 8c16g的,会发现 cpu average和cpu 利用率、memeory都没上去 只是请求响应时间上去了。问题有很多,发现大部分都是线程池大小设置不合理导致的,每次出现问题都是人工去分析CPU load、cpu 利用率、memory 等各项指标来,结合业务重行设定线程池大小。很多开发还不一定能分析对,分析还比较麻烦,修改完后还要重启机器(有的开发没分析到问题直接申请加机器)、压测验证等等一系列问题。

    Java里的线程池ThreadPoolExecutor设定线程池大小都是固定的(指corePoolSize和maximumPoolSize这些值都不能改变),不能实现真正意义上的线程池动态扩展,设置过小无法合理利用机器,设置过大不小心就内存溢出了。

    为什么我们不能去自己写一个智能动态扩展的线程池呢?

    设定合适的算法,通过实时监控分析cpu、memory、响应时间 来动态设置线程池的大小和队列的大小。

    开源jar包 sigar 封装好了对机器的os、cpu、memory、网络等实时监控,在Java中每开启一个线程大约多占用内存0.5M左右,通过我们给定的合适算法,设计一个动态扩展的线程池,完全可以避免生产机器利用不上去,又报noAvaliableThradException问题。先做个mark,见证后续是否有人实现,或自己实现应用于生产中。

  • 相关阅读:
    读《SQL优化核心思想》:你不知道的优化技巧
    MySQL 索引建立原则及注意事项
    MySQL 捕获有问题的SQL-慢查日志 实例
    MySQL 分区间进行数据展示 实例
    MySQL 删除重复数据实例
    MySql 索引优化实例
    JDK1.6 Java.lang.Null.Pointer.Exception
    关于 MySQL LEFT JOIN 不可不知的事
    搞定queryString
    数据库不得不说的陷阱
  • 原文地址:https://www.cnblogs.com/Roysatm/p/9152855.html
Copyright © 2011-2022 走看看