线程池

以Tomcat8.5为例，HTTP1.1 官方文档配置地址 https://tomcat.apache.org/tomcat-8.5-doc/config/http.html <Connector port="8080" acceptCount="100" maxConnections="200" minSpareThreads="10" maxThreads="200"/> acceptCount :请求等到队列大小。当Tomcat没有空闲线程处理连接请求时，新来的链接请求将放入等待队列，默认为100。当队列超过acceptCount后新连接将被拒绝。 maxConnections :Tomcat能处理的最大并发连接数.当超过后还会接收连接并放入等待队列(acceptCount控制)，连接会等待，不能被处理。BIO默认是maxThreads. 对于NIO和NIO2，默认值为10000。对于APR /native，默认值为8192。 仅对于NIO / NIO2，将该值设置为-1将禁用maxConnections功能，并且不计算连接数。 minSpareThreads :线程池最小线程数，默认为10。该配置指定线程池可以维持的空闲线程数量。(始终保持运行状态的最小线程数。 这包括活动线程和空闲线程。 如果未指定，则使用默认值10。 如果执行程序与此连接器相关联，则此属性将被忽略

本篇文章主要介绍了Python之多线程爬虫抓取网页图片的示例代码，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧 目标 嗯，我们知道搜索或浏览网站时会有很多精美、漂亮的图片。 我们下载的时候，得鼠标一个个下载，而且还翻页。 那么，有没有一种方法，可以使用非人工方式自动识别并下载图片。美美哒。 那么请使用python语言，构建一个抓取和下载网页图片的爬虫。 当然为了提高效率，我们同时采用多线程并行方式。 思路分析 Python有很多的第三方库，可以帮助我们实现各种各样的功能。问题在于，我们弄清楚我们需要什么： 1)http请求库，根据网站地址可以获取网页源代码。甚至可以下载图片写入磁盘。 2)解析网页源代码，识别图片连接地址。比如正则表达式，或者简易的第三方库。 3)支持构建多线程或线程池。 4)如果可能，需要伪造成浏览器，或绕过网站校验。(嗯，网站有可能会防着爬虫 😉) 5)如果可能，也需要自动创建目录，随机数、日期时间等相关内容。 如此，我们开始搞事情。O(∩_∩)O~ 环境配置 操作系统：windows 或 linux 皆可 Python版本：Python3.6 ( not Python 2.x 哦) 第三方库 urllib.request threading 或者 concurrent.futures 多线程或线程池(python3.2+) re

线程的创建和效率都需要消耗处理器（cpu）的资源，所以我们在使用线程时需要注意，你的每一个动作都是需要为它买单的，也正是因为线程的使用需要谨慎，所以java对线程的管理也进行了封装，就是今天要说的线程池，目前java主要封装了大概４大种类型的线程池，下面简单来介绍一下。 四大类型的线程池 newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。 newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。 newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。 newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。 线程池里主要的三个参数 corePoolSize： 线程池的基本大小，即在没有任务需要执行的时候线程池的大小，并且只有在工作队列满了的情况下才会创建超出这个数量的线程。这里需要注意的是：在刚刚创建ThreadPoolExecutor的时候，线程并不会立即启动，而是要等到有任务提交时才会启动，除非调用了prestartCoreThread/prestartAllCoreThreads事先启动核心线程

SpringBoot2 线程池的定义和使用 定义线程池 @Slf4j @EnableAsync @Configuration public class AsyncExecutorConfig implements AsyncConfigurer { @Bean public ThreadPoolTaskExecutor asyncServiceExecutor() { //返回可用处理器的虚拟机的最大数量不小于1 int cpu = Runtime.getRuntime().availableProcessors(); log.info("start asyncServiceExecutor cpu : {}", cpu); ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); //配置核心线程数 executor.setCorePoolSize(cpu); //配置最大线程数 executor.setMaxPoolSize(cpu); //配置队列大小 executor.setQueueCapacity(50); //用来设置线程池关闭的时候等待所有任务都完成再继续销毁其他的Bean executor.setWaitForTasksToCompleteOnShutdown(true); /

1：先写一个Runnable。 1 package ThreadPool; 2 3 /** 4 * @ProjectName: smartdata 5 * @Package: ThreadPool 6 * @ClassName: TicketRunnable 7 * @Author: heluwei 8 * @Description: 9 * @Date: 2020/3/23 18:55 10 * @Version: 1.0 11 */ 12 public class TicketRunnable implements Runnable { 13 14 // 为了保持票数的一致，票数要静态 15 static int tick = 20; 16 // 创建一个静态钥匙 17 static Object ob = "aa";//值是任意的 18 // 重写run方法，实现买票操作 19 @Override 20 public void run() { 21 while (tick > 0) { 22 synchronized (ob) {// 这个很重要，必须使用一个锁， 23 // 进去的人会把钥匙拿在手上，出来后才把钥匙拿让出来 24 if (tick > 0) { 25 System.out.println(Thread.currentThread().getName() +

3 月，跳不动了？>>> 　　 什么是 Hystrix 　　 　　Hystrix 源自 Netflix 团队于 2011 年开始研发。2012年 Hystrix 不断发展和成熟，Netflix 内部的许多团队都采用了它。如今，每天在 Netflix 上通过 Hystrix 执行数百亿个线程隔离和数千亿个信号量隔离的调用。极大地提高了系统的稳定性。 　　在分布式环境中，不可避免地会有许多服务依赖项中的某些服务失败而导致 雪崩效应 。Hystrix 是一个库，可通过添加等待时间容限和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体稳定性。 　　 雪崩效应 　　 　　在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问 A 服务，而 A 服务需要调用 B 服务，B 服务需要调用 C 服务，由于网络原因或者自身的原因，如果 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。以下图示完美解释了什么是雪崩效应。 　　 　　当一切服务正常时

public ThreadPoolExecutor( int corePoolSize, 　　　　　　　　　　　　　　//核心池的大小。 int maximumPoolSize,　　 //池中允许的最大线程数，这个参数表示了线程池中最多能创建的线程数量 long keepAliveTime,　　　　　　　　　　 //当线程数大于corePoolSize时，终止前多余的空闲线程等待新任务的最长时间 TimeUnit unit,　　　　　　　　　　　　　 //keepAliveTime时间单位 BlockingQueue<Runnable> workQueue, //存储还没来得及执行的任务 ThreadFactory threadFactory,　　　　 //执行程序创建新线程时使用的工厂 RejectedExecutionHandler handler //由于超出线程范围和队列容量而使执行被阻塞时所使用的处理程序 ) corePoolSize与maximumPoolSize举例理解 1、池中线程数小于corePoolSize，新任务都不排队而是直接添加新线程 2、池中线程数大于等于corePoolSize，workQueue未满，首选将新任务加入workQueue而不是添加新线程 3、池中线程数大于等于corePoolSize，workQueue已满

版权声明：本文出自汪磊的博客，转载请务必注明出处。 Java线程池技术属于比较“古老”而又比较基础的技术了，本篇博客主要作用是个人技术梳理，没什么新玩意。 一、Java线程池技术的由来 我们平时使用线程来进行异步操作时，线程的创建，销毁等相对来说都是比较消耗资源的，试想这样一个业务情景：高并发请求，但是每次请求的时间非常短。如果我们为每一个请求都单独创建一个线程来执行，就会消耗大量设备资源，使设备处于高负荷状态，显然这样的处理就有很大问题了。这时候我们就可以用线程池技术来解决了，我们在线程池中创建若干条线程，当有任务需要执行时就从该线程池中获取一个线程来执行任务，如果一时间任务过多，超出线程池的线程数量，那么后面的线程任务就进入一个等待队列进行等待，直到线程池有线程处于空闲时才从等待队列获取要执行的任务进行处理，这样就减少了线程创建和销毁的开销，实现了线程的复用。 二、Executor框架介绍 首先对整体框架有个大概了解，如图： Executor是个接口，就定义了一个void execute(Runnable command)方法。 ExecutorService同样是一个接口并且继承自 Executor 接口，对其方法进行扩展，其中最重要的是<T> Future<T> submit(Callable<T> task)方法，关于 Callable ， Future ， Future

3 月，跳不动了？>>> 很多开发者谈到Java多线程开发，仅仅停留在new Thread(...).start()或直接使用Executor框架这个层面，对于线程的管理和控制却不够深入，通过读《Java并发编程实践》了解到了很多不为我知但又非常重要的细节，今日整理如下。 不应用线程池的缺点 有些开发者图省事，遇到需要多线程处理的地方，直接new Thread(...).start()，对于一般场景是没问题的，但如果是在并发请求很高的情况下，就会有些隐患： 新建线程的开销。线程虽然比进程要轻量许多，但对于JVM来说，新建一个线程的代价还是挺大的，决不同于新建一个对象 资源消耗量。没有一个池来限制线程的数量，会导致线程的数量直接取决于应用的并发量，这样有潜在的线程数据巨大的可能，那么资源消耗量将是巨大的 稳定性。当线程数量超过系统资源所能承受的程度，稳定性就会成问题 制定执行策略 在每个需要多线程处理的地方，不管并发量有多大，需要考虑线程的执行策略 任务以什么顺序执行 可以有多少个任何并发执行 可以有多少个任务进入等待执行队列 系统过载的时候，应该放弃哪些任务？如何通知到应用程序？ 一个任务的执行前后应该做什么处理 线程池的类型 不管是通过Executors创建线程池，还是通过Spring来管理，都得清楚知道有哪几种线程池： FixedThreadPool：定长线程池

3 月，跳不动了？>>> 如何合理地估算线程池大小？ 这个问题虽然看起来很小，却并不那么容易回答。大家如果有更好的方法欢迎赐教，先来一个天真的估算方法：假设要求一个系统的TPS（Transaction Per Second或者Task Per Second）至少为20，然后假设每个Transaction由一个线程完成，继续假设平均每个线程处理一个Transaction的时间为4s。那么问题转化为： 如何设计线程池大小，使得可以在1s内处理完20个Transaction？ <!-- more --> 计算过程很简单，每个线程的处理能力为0.25TPS，那么要达到20TPS，显然需要20/0.25=80个线程。 很显然这个估算方法很天真，因为它没有考虑到CPU数目。一般服务器的CPU核数为16或者32，如果有80个线程，那么肯定会带来太多不必要的线程上下文切换开销。 再来第二种简单的但不知是否可行的方法（N为CPU总核数）： 如果是CPU密集型应用，则线程池大小设置为N+1 如果是IO密集型应用，则线程池大小设置为2N+1 如果一台服务器上只部署这一个应用并且只有这一个线程池，那么这种估算或许合理，具体还需自行测试验证。 接下来在这个文档：服务器性能IO优化 中发现一个估算公式： 最佳线程数目 = （（线程等待时间+线程CPU时间）/线程CPU时间 ）* CPU数目