线程数

大家面试过程中肯定被问道过线程池。为什么要使用线程池呢？因为在系统中频繁创建线程会造成很大的CPU消耗。而且用完的线程要等待GC回收也会造成消耗。 下面我们就来学习下最常用的线程池 ThreadPoolExecutor， 首先先来看看它的构造方法： public ThreadPoolExecutor(int corePoolSize,int maximumPoolSize,long keepAliveTime,TimeUnit unit,BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory,RejectedExecutionHandler handler) { if (corePoolSize < 0 || maximumPoolSize <= 0 || maximumPoolSize < corePoolSize || keepAliveTime < 0) throw new IllegalArgumentException(); if (workQueue == null || threadFactory == null || handler == null) throw new NullPointerException(); this.acc = System.getSecurityManager() =

1. 通过Executors创建线程池的弊端 在创建线程池的时候，大部分人还是会选择使用Executors去创建。 下面是创建定长线程池（FixedThreadPool）的一个例子，严格来说，当使用如下代码创建线程池时，是不符合编程规范的。 ExecutorService fixedThreadPool = Executors.newFixedThreadPool(5); 原因在于：（摘自阿里编码规约） 线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。 说明：Executors各个方法的弊端： 1）newFixedThreadPool和newSingleThreadExecutor:   主要问题是堆积的请求处理队列可能会耗费非常大的内存，甚至OOM。 2）newCachedThreadPool和newScheduledThreadPool:   主要问题是线程数最大数是Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至OOM。 2. 通过ThreadPoolExecutor创建线程池 所以，针对上面的不规范代码，重构为通过ThreadPoolExecutor创建线程池的方式。 /** * Creates a new {@code

控制并发线程数的Semaphore Semaphore（信号量）是用来控制同时访问特定资源的线程数量，它通过协调各个线程，以保证合理的使用公共资源。 Semaphore比作是控制流量的红绿灯。比如××马路要限制流量，只允许同时有一百辆车在这条路上行使，其他的都必须在路口等待，所以前一百辆车会看到绿灯，可以开进这条马路，后面的车会看到红灯，不能驶入××马路，但是如果前一百辆中有5辆车已经离开了××马路，那么后面就允许有5辆车驶入马路，这个例子里说的车就是线程，驶入马路就表示线程在执行，离开马路就表示线程执行完成，看见红灯就表示线程被阻塞，不能执行。 应用场景： Semaphore可以用于做流量控制，特别是公用资源有限的应用场景，比如数据库连接。假如有一个需求，要读取几万个文件的数据，因为都是IO密集型任务，我们可以启动几十个线程并发地读取，但是如果读到内存后，还需要存储到数据库中，而数据库的连接数只有10个，这时我们必须控制只有10个线程同时获取数据库连接保存数据，否则会报错无法获取数据库连接。这个时候，就可以使用Semaphore来做流量控制，如下所示。 package pers . zhang . part6 ; import java . util . concurrent . ExecutorService ; import java . util . concurrent

基于JMeter5.1.1+File Browser2.1.0 JMeter发起压测 File Browser作为文件服务器 一、目录结构： Dockerfile文件： FROM ubuntu:18.04 # 基础镜像 MAINTAINER yangjianliang <526861348@qq.com> # 作者 RUN sed -i s@/archive.ubuntu.com/@/mirrors.aliyun.com/@g /etc/apt/sources.list # 设置apt源为阿里云源 RUN apt-get clean && \ apt-get update && \ apt-get upgrade -y # 检查软件包并升级 RUN ln -fs /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \ apt-get install -y \ tzdata && \ rm -rf /var/lib/apt/lists/* # 设置时区 ADD jdk-8u201-linux-x64.tar.gz /usr/local/java ENV JAVA_HOME=/usr/local/java/jdk1.8.0_201 ENV JRE_HOME=/usr/local/java/jdk1.8.0_201/jre ENV

测试需求： 测试20个用户访问www.baozhenart.com在负载达到30QPS时的平均响应时间 　　QPS：Query Per Second每秒查询率。是一台查询服务器每秒能够处理的查询次数。在因特网上，作为域名系统服务器的性能经常用每秒查询率来衡量。 测试步骤： 第一步：添加线程组 线程组主要包含三个参数：线程数、准备时长、循环次数 　　 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里就设置多少个线程数 准备时长（单位为s）:设置虚拟用户数需要多长时间全部启动。如果线程数为20，准备时长为10，则需要在10秒钟启动20个线程。也就是每秒钟启动2个线程。 循环次数：每个线程发送请求的次数。如果线程数为20，循环次数为5，那么每个线程发送5次请求。总请求数为20*5=100.如果勾选了"永远"，那么所有线程一直发送请求，一直到停止运行脚本 第二步：增加HTTP请求 一个HTTP请求有着许多的配置参数，下面详细介绍 协议：向目标服务器发送HTTP请求时的协议，可以是http或者https，默认为http。 方法：发送HTTP请求的方法，包括GET、POST、HEAD、PUT、DELETE等 Content encoding:内容的编码方式，默认值为iso8859 路径：目标URL路径（不包括服务器地址和端口） 自动重定向：如果选中该选项

性能调优系列前序文章索引： 必须掌握的性能调优 ：老兵哥结合个人经历解释了程序员往架构师方向发展时为什么要跨越性能调优这一关，以及介绍了从 X、Y、Z 三个维度优化性能的思路。 从 X 维度优化系统的性能 ：老兵哥分享了从 X 维度优化系统性能的思路，包括让客户端分计算存储任务、优化交互设计等，主要是作为引子拓宽我们性能调优的思路。 程序员在转型架构师的过程中需要建立流程化、结构化、系统化的思维方式，而性能调优是非常难得的契机，它既给了我们压力，也给了我们动力，跨越它就是突破自己的过程。 X 维度， 即业务维度，技术始终是服务业务的，任何技术问题的原点就是业务需求。在启动技术层面的性能优化之前，我们有必要先审视一下业务流程是否合理，交互设计上有没有可以优化的空间等。 Y 维度， 待业务维度优化完毕，接下来就是审视技术在实现当前业务流程或交互设计的全链路上有没有可优化的地方，即 HTTP 请求处理全流程，从浏览器到应用容器，再到 Spring、Hibernate、 数据库 等。 Z 维度 ，除了沿着 HTTP 请求的横向链路，我们还要审视支持应用系统的纵向技术栈，从上到下包括 JVM 、操作系统和硬件等，这是整套应用系统运行的环境，许多性能问题都跟运行环境存在关系。 Y 维度 ，就是从业务 HTTP 请求的横向处理流程来看，HTTP 请求会穿越网络、计算机、应用容器（Tomcat）

上一节中，我们了解了jmeter的一此主要元件，那么这些元件如何使用到性能测试中呢。这一节创建一个简单的测试计划来使用这些元件。该计划对应的测试需求。 1）测试目标网站是fnng.cnblogs.com 2）测试目的是该网站在负载达到20 QPS 时的响应时间。 QPS 解释 　　QPS : Query Per Second 每秒查询率。是一台查询服务器每秒能够处理的查询次数。在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。 　　为了达成预期的测目的，需要需要在jmeter中建立一个测试计划。因为本次测试仅要求完成对fnng.cnblogs.com博客首页请求，因此只需要使用HTTP Request Sampler 即可。 建立测试计划 　　启动jmeter后，jmeter会自动生成一个空的测试计划，用户可以基于该测试计划建立自己的测试计划。 添加线程组 　　一个性能测试请求负载是基于一个线程组完成的。一个测试计划必须有一个线程组。测试计划添加线程组非常简单。在测试计划右键弹出下拉菜单（添加-->Threads(Users)--->线程组）中选择线程组即可。 　　jmeter中 每个测试计划至少需要包含一个线程组，当然也可以在一个计划中创建多个线程组，那么多个线程组之间又会怎样的顺序执行（串行还是并行）？在测试计划下面多个线程是并行执行的

转自：虫师博客 https://www.cnblogs.com/fnng/archive/2012/12/22/2829479.html 个人总结： 关键词：固定QPS限制，线程组设置 测试需求。 1）测试目标网站是fnng.cnblogs.com 和 tt-topia.rhcloud.com 2）测试目的是该网站在负载达到20 QPS 时的响应时间。 QPS 解释 　　QPS : Query Per Second 每秒查询率。是一台查询服务器每秒能够处理的查询次数。在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。 　　为了达成预期的测目的，需要需要在jmeter中建立一个测试计划。因为本次测试仅要求完成对fnng.cnblogs.com 和 tt-topia.rhcloud.com 两个博客首页请求，因此只需要使用HTTP Request Sampler 即可。 建立测试计划 　　启动jmeter后，jmeter会自动生成一个空的测试计划，用户可以基于该测试计划建立自己的测试计划。 添加线程组 　　一个性能测试请求负载是基于一个线程组完成的。一个测试计划必须有一个线程组。测试计划添加线程组非常简单。在测试计划右键弹出下拉菜单（添加-->Threads(Users)--->线程组）中选择线程组即可。 　　jmeter中 每个测试计划至少需要包含一个线程组

本文来自 网易云社区 作者： 方金德 “咚咚”，接连收到好几个报警短信，显示线上集群的几个tomcat应用的接连端口异常。不好，线上可能出状况了，访问网站，果然已经显示为维护中了。赶紧登陆到服务器，但服务器的cpu，load，内存，io等基本指标都还是挺正常的，应用日志端也没有明显异常信息，不过nginx的访问日志的确显示后端服务器都已基本为504请求超时了。不管那么多了，距离上次发布已经有几个小时了，应该不是新版本bug直接导致的问题，先尝试不回滚重启吧。于是火速重启了集群中一个节点，很快线上应用访问正常了。然后把另外两个节点的jvm的stack和memory信息导出来后，也重启后加回到线上。 线上是正常了，但我们其实并没有找到问题的原因。没有找到问题的诱因，也就意味着这个问题可能还会再发生。和相关的同事们再一起排查了一遍线上应用日志和tomcat容器日志，也没有发现什么可挖掘的异常点。再跑到网易的监控平台看历史的监控数据，系统层面的cpu、load、 中断、 memory、 swap、 ioutil、网络流量等都没有特别的异常；jvm层面的gc、thread数也都没有什么明显异常。gc没有问题，直接放弃了memory dump信息的查看。再简单地看了下jstack信息，好像也没有什么异常，统计了下线程数，跟线上的线程数也差不多，猜测应该也不是属于并发超限吧。。。

最近工作种常用到ThreadPoolExecutor这个对象， 这是一个并发编程中非常常用的对象。因为和并发编程相关所以它存在于java.util.concurrent这包中。 创建这个对象的基本方法如下： 今天主要想研究一下最后一个参数RejectedExecutionHandler对整个线程池的影响。首先写出需要用到测试代码如下： import java.io.Serializable; import java.util.concurrent.*; public class ThreadPoolExecutorTest { private static int produceTaskSleepTime = 1000; // 一秒add一个任务 private static int consumeTaskSleepTime = 60000; //每个任务停留10秒这样结果更明显清楚 private static BlockingQueue<Runnable> queue = new ArrayBlockingQueue<Runnable>(2); //缓存队列数 private static int produceTaskMaxNumber = 51; //总线程数 private static int corePoolSize = 2; // private static