线程数

一、概述 1. new Thread的弊端 （1）每次new Thread新建对象性能差。 （2）线程缺乏统一管理，可能无限制新建线程，相互之间竞争，及可能占用过多系统资源导致死机或oom（内存溢出）。 （3）缺乏更多功能，如定时执行、定期执行、线程中断。 2. 线程池 线程池是指管理同一组同构工作线程的资源池，线程池是与工作队列(Work Queue)密切相关的，其中在工作队列中保存了所有等待执行的任务。工作线程(Worker Thread)的任务很简单：从工作队列中获取一个任务，执行任务，然后返回线程池并等待下一个任务。 3. 线程池的组成 一个线程池包括以下四个基本组成部分： （1）线程池管理器（ThreadPool）：用于创建并管理线程池，包括 创建线程池，销毁线程池，添加新任务； （2）工作线程（PoolWorker）：线程池中线程，在没有任务时处于等待状态，可以循环的执行任务； （3）任务接口（Task）：每个任务必须实现的接口，以供工作线程调度任务的执行，它主要规定了任务的入口，任务执行完后的收尾工作，任务的执行状态等； （4）任务队列（taskQueue）：用于存放没有处理的任务。提供一种缓冲机制。 4. 什么时候适合使用线程池 在多线程应用中，如果大量的资源都耗费在创建和销毁线程上，那么可以使用线程池。 5. 合理利用线程池带来的好处 （1）降低资源消耗

文章目录 授人以鱼不如授人以渔 目的 服务器资源 Tomcat配置优化 Linux环境安装运行Tomcat8 AJP连接 执行器（线程池） 3种运行模式 部署测试用的web项目 查看服务器信息 部署web应用 使用Apache JMeter进行性能测试 下载安装 修改语言 创建接口的测试用例 启动与进行接口测试 查看测试报告 调整Tomcat参数进行优化 禁用AJP连接 设置线程池 最大线程数为150，初始为4 最大线程数为500，初始为50 最大线程数为1000，初始为200 最大线程数为5000，初始为1000 设置最大等待队列数 设置nio2的运行模式 参数说明与最佳实践 执行器参数说明(加粗是重点) 执行器最佳实践 连接器参数说明 通用属性(加粗是重点) 标准实现(加粗是重点) 连接器最佳实践 调整JVM参数进行优化 设置并行垃圾回收器 查看gc日志文件 调整年轻代大小 设置G1垃圾回收器 JVM配置最佳实践 总结 授人以鱼不如授人以渔 本博客的目的不在于给出最佳配置，而是带领开发者，能够从实际情况出发，通过不断的调节tomcat和jvm参数，去发现吞吐量，平均响应时间和错误率等信息的变化，同时根据服务器的cpu和内存等信息，结合接口的业务逻辑，最好是测试使用率最高，并发最大，或者是最重要的接口(比如下单支付接口)，设置最优的tomcat和jvm配置参数。 目的

扫描下方二维码或者微信搜索公众号 菜鸟飞呀飞 ，即可关注微信公众号，阅读更多 Spring源码分析 和 Java并发编程 文章。 前言   无论是在工作中，还是在书本中，我们都可以听到或者看到关于线程在使用时的一些建议：不要在代码中自己直接创建线程，而是通过线程池的方式来使用线程。使用线程池的理由大致可以总结为以下几点。 1. 降低资源消耗。线程是操作系统十分宝贵的资源，当多个人同时开发一个项目时，在互不知情的情况下，都自己在代码中创建了线程，这样就会导致线程数过多，而且线程的创建和销毁，在操作系统层面，需要由 用户态切换到内核态 ，这是一个 费时费力 的过程。而使用线程池可以避免频繁的创建线程和销毁线程，线程池中线程可以重复使用。 2. 提高响应速度。当请求到达时，由于线程池中的线程已经创建好了，使用线程池，可以省去线程创建的这段时间。 3. 提高线程的可管理性。线程是稀缺资源，当创建过多的线程时，会造成系统性能的下降，而使用线程池，可以对线程进行统一分配、调优和监控。   线程池的使用十分简单，但是会用不代表用得好。在面试中，基本不会问线程池应该怎么用，而是问线程池在使用不当时会造成哪些问题，实际上就是考察线程池的实现原理。因此搞明白线程池的实现原理是很有必要的一件事，不仅仅对面试会有帮助，也会让我们在平时工作中避过好多坑。 实现原理   在线程池中存在几个概念：核心线程数

本文，是《tomcat的maxConnections、maxThreads、acceptCount》篇 ，为大家解读tomcat的maxConnections、maxThreads、acceptCount， 大家可以藏好，一定有用的到时候 。 怎么配置tomcat，才能使得自己的服务效率更高呢？ 首先，这和tomcat的使用的IO模式有关 关于Java IO模式、以及IO处理的线程模型等基础的通信框架的知识，是Java程序员的重要、必备的内功，具体请参见尼恩编著的《Netty、Zookeeper、Redis高并发实战》一书，这里不做过多的赘述。 其次，也和tomcat的配置参数有关 尤其是以下三个配置项：maxConnections、maxThreads、acceptCount。 1.4.1 Tomcat的高效配置 Tomcat的maxConnections、maxThreads、acceptCount三大配置，分别表示最大连接数，最大线程数、最大的等待数，可以通过application.yml配置文件来改变这个三个值，一个标准的示例如下： server: tomcat: uri-encoding: UTF-8 #最大工作线程数，默认200, 4核8g内存，线程数经验值800 #操作系统做线程之间的切换调度是有系统开销的，所以不是越多越好。 max-threads: 1000 #

在做并发测试的时候，需要参考tomcat的maxThreads、acceptCount（最大线程数、最大排队数）； tomcat 的Connector配置如下 <</span>Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="800" acceptCount="1000"/> 其中最后两个参数意义如下： maxThreads ：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200 acceptCount ：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100 这两个值如何起作用，请看下面三种情况 情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。 情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。 情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused maxThreads如何配置

1、主要参数说明 corepoolsize核心线程数、maxpoolsize最大线程数、keepalivetime闲置线程收回时间设置、workQueue工作队列（synchronizeQueue、 LinkedBlockingQueue 、ArrayListBlockingQueue）、unit设置keepalivetime是以秒、分钟为单位、threadFactory创建线程工厂。 2、执行顺序 如果工作队列选择的是 LinkedBlockingQueue ,线程池中的线程数达到corepoolsize核心线程数后，会将任务放入到队列中，如果队列满了，会继续创建线程，达到maxpoolsize最大线程数后，可以选择几种策略处理，抛异常拒绝新任务、丢弃新任务或者挤占已有任务。 如果 LinkedBlockingQueue设置是无边界，则 maxpoolsize设置无效。 如果工作 队列是synchronizeQueue，线程池中的线程数达到corepoolsize核心线程数后会继续创建线程，超过设置的最大线程数后报错。 3、 newFixedThreadPool 和 newSingleThreadExector使用的是LinkedBlockingQueue的无界模式 来源： https://my.oschina.net/u/3745555/blog/3131719

1、内存优化： 优化内存，主要是在bin/catalina.bat或bin/catalina.sh 配置文件中进行。linux上，在catalina.sh中添加： JAVA_OPTS="-server -Xms1G -Xmx2G -Xss256K -Djava.awt.headless=true -Dfile.encoding=utf-8 -XX:MaxPermSize=256m -XX:PermSize=128M -XX:MaxPermSize=256M" 其中： • -server：启用jdk的server版本。 • -Xms：虚拟机初始化时的最小堆内存。 • -Xmx：虚拟机可使用的最大堆内存。 #-Xms与-Xmx设成一样的值，避免JVM因为频繁的GC导致性能大起大落 • -XX:PermSize：设置非堆内存初始值,默认是物理内存的1/64。 • -XX:MaxNewSize：新生代占整个堆内存的最大值。 • -XX:MaxPermSize：Perm（俗称方法区）占整个堆内存的最大值，也称内存最大永久保留区域。 1）错误提示：java.lang.OutOfMemoryError:Java heap space Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，有可能导致系统无法运行。常见的问题是报Tomcat内存溢出错误，Outof

一个ASP.NET项目在部署到生产环境时，当用户并发量达到200左右时，IIS出现了明显的请求排队现象，发送的请求都进入等待，无法及时响应，系统基本处于不可用状态。因经验不足，花了很多时间精力解决这个问题，本文记录了我查找问题的过程和最后解决方案，供大家参考。 软硬件环境： IBM刀片服务器，Intel至强处理器，4物理核，16个逻辑核心，内存32G Windows Server2008 Enterprise R2， ASP.NET 4.0 Webform IIS7.5 集成模式 当发现请求明显延迟，没有被即时处理的现象，首先就要查看Windows自带的性能日志Performance Monitor。 由于我注意到只有对于.aspx或.ashx的请求才会延迟，而.htm或.jpg文件都是即时响应的，所以很明显问题出在ASP.NET上，于是我选择了性能监视器中的ASP.NET 4.0中的2个主要计数器：Requests Current（当前请求数）, Requests Queued（被排队的请求数）进行观察。通过观察发现，当前请求数达到200左右时，被排队的请求数就从0开始上升，一直到50左右，如果请求数继续上升，则被排队数也随之上升。当被排队的请求数>0时，就意味着这个时候去访问任何.aspx页面，页面都会处于长时间等待中，没有任何响应，直到IIS处理完了其他请求

一 机器部署 1、机器组成 7台机器，均为16G内存 每台服务器均有4个CPU，2核 2、运行环境配置 3、刷盘方式 每台机器master机器均采用异步刷盘方式 二 性能评测 1、评测目的 多线程环境下，测试producer端的TPS 和 consumer端的TPS。 2、评测指标 （1）生产者producer TPS、线程个数、发送成功数量、发送失败数量、接收成功数量、接收失败数量、发送消息成功总耗时。 （2）消费者consumer TPS、接收消息总数、消息存储总耗时，消息存储平均耗时、消息消费总耗时、消息消费平均耗时。 3、评测逻辑 （1）固定消息长度，producer端发送消息body的字符串默认100字符长度。 （2）输入不同的线程数，产生不同组的producer，记录发送消息的TPS、发送成功数和消息消费的TPS、消费成功数等等。 （3）根据多组测试数据，分析平均的生产TPS和平均消费TPS。 4、评测步骤 （1）创建性能测试的topic，名称为BenchmarkTopicTest。 队列个数默认8个。 （2）输入线程数、消息长度、是否开启message的key值，并做表格记录TPS。 （3）针对特定场景，保持线程数不变，增加消息message的size，记录producer端和consumer端的TPS，并做表格记录。 编号 TPS (Producer) TPS

转载至： 业务系统压测实践建议 总原则 无论是对HTTP接口、Thrift接口或者Web Service接口进行压测，发起测试的机器都要尽可能靠近被压测的应用服务器，这样才能得到更准确的压测结果（有效减少网络传输开销带来的干扰） 排除非业务因素影响：压测前先确认硬件（CPU、内存、IO、网络等）、被压测接口用到的中间件（Tomcat、Nginx、Redis、RabbitMQ等）的配置信息和健康状况。如果存在硬件故障或者中间件故障，则需要先排除掉 确定压测目标，比如是压测tps、内存消耗量还是其他如要能支持多少并发用户，达到多少tps 确定一个压测基准，比如压测某个HTTP API接口的tps时，可以先压测心跳检测接口（业务逻辑最少），比如压测得到5000tps，那么就可以断定其他业务逻辑更复杂的HTTP API接口的极限tps不可能超过5000tps，无论你怎么优化（这里的优化特指业务性能优化，如果中间件优化了，则需要重新确定压测基准） 压测前最好用ping、traceroute查看下网络连通状况 一般先对单台服务器做压测，单台服务器压测达到期望的压测指标后再扩展到集群环境对多台服务器做压测 压测服务器尽可能和线上服务器一致或者类似，确认发起测试的服务器本身不存在性能瓶颈（比如还没开始压测，发起测试的机器CPU就已经100%、测试机器在创建多一些线程的时候CPU增长很快）