首页 文章 精选 留言 我的

精选列表

搜索[数据库连接池]，共10038篇文章
优秀的个人博客,低调大师

BeeCP-3.1.7 发布，高性能连接池

1：版本下载(java7) <dependency> <groupId>com.github.chris2018998</groupId> <artifactId>beecp</artifactId> <version>3.1.7</version> </dependency> 2：更新内容 优化超时Cms处理 缩短池中一些方法体 3：Springboot启动器同步更新 <dependency> <groupId>com.github.chris2018998</groupId> <artifactId>beecp-spring-boot-starter</artifactId> <version>1.5.3</version> </dependency> 4：项目地址 国内地址：https://gitee.com/mirrors/BeeCP 国外地址：https://github.com/Chris2018998/BeeCP
2021-04-18
优秀的个人博客,低调大师

浅析Tomcat高并发之连接池、线程池

记得大学的《网络工程》有一个课后作业：用Java实现一个web服务器，当时想的是为了提高吞吐量，可以用多线程实现，即对于每一个客户端请求连接，都启动一个线程来处理，处理逻辑大概就是从socket里面读取http请求，解析执行请求，执行完把response写回socket，线程结束销毁。用多线程实现确实提高了吞吐量，但是也有一些问题：1）不断的线程创建销毁需要耗费大量的开销；2）线程之间的切换需要耗费很多开销；3）Java有创建最多线程数量的限制，具体可参考https://www.iteye.com/blog/jzhihui-1271122。 如果要优化上面的实现，可以怎么做呢？其实参考tomcat的发展进程，就是优化的方向。 1 Tomcat处理用户请求的入口组件叫做Connector，其有两个主要的实现：BIO（blocking io）和NIO（non-blocking io）。 简单讲，BIO的实现就是对上面多线程版本的一个改进，主要点在于把“每来一个连接启动一个线程处理”改成“每来一个连接都提交给线程池处理”。虽然线程池根据不同的配置，其工作行为会有所不同，但一般来讲，使用线程池的原则是：只需创建少量的线程就可以完成大量任务的执行，由于同时至多只有固定量的线程执行，剩余的任务会被放进queue里面缓冲起来，从这个角度看，这是一个典型的生产者-消费者模型。回到tomcat BIO，acceptor不断的接收连接，然后提交给线程池执行，acceptor就是生产者；线程池的每一个线程就是消费者，负责处理请求。 由于socket连接是长连接，连接的创建销毁也是很耗资源的，于是http协议增加了一个keep-alive header，这个header的意思是提示服务器端，在返回http response之后，不要断开socket，继续处理后续http请求，这样做的目的就是为了提高资源的可重用性。那么，对于tomcat BIO的实现，在keep-alive场景下，会有什么问题呢？如果一个线程处理的socket需要保持keep-alive，其在执行完一个http请求之后，需要阻塞在那里以等待下一个http请求，不能马上结束（直到timeout）；在某些情况下，这样就可能存在大量的阻塞线程，新的连接不能被处理。 基于此，NIO就可以解决这个问题。NIO和BIO在请求处理部分的实现是一致的，都是基于线程池；不同的地方是：NIO的acceptor基于jdk nio实现，在收到一个连接之后，会把socketChannel注册到poller的selector上面，当socketChannel有数据可读时，poller就把此连接提交给线程池处理。回到上面keep-alive的场景，当一个线程处理完一个http请求之后，就可以马上结束，当前连接则回到selector继续监听接下来的http请求。所以，基于NIO的执行线程就不会出现基于BIO的阻塞情况。 NIO的核心在于selector，selector可以识别到已经ready的连接和没有ready的连接；在之前的一篇多线程文章（对比Java和.NET多线程编程）里面提到过，jdk的concurrency API有一个CompletionService类，就有点类似于nio的原理。 由于NIO天生的优势，tomcat从8.0版本开始就把NIO设成默认的Connector，而从8.5版本开始直接就把BIO去掉了。 2 在tomcat的官网有下面一段关于如何高并发处理请求的描述： Each incoming request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxThreads attribute). If still more simultaneous requests are received, they are stacked up inside the server socket created by the Connector, up to the configured maximum (the value of the acceptCount attribute). Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them. - https://tomcat.apache.org/tomcat-7.0-doc/config/http.html 个人觉得其没有反映出maxConnections这个参数的作用，所以应该是：如果maxConnections小于maxThreads，最大创建的线程数就是maxConnections的值，最大连接数也是maxConnections的值；但是如果maxConnections大于maxThreads，最大创建的线程数就是maxThreads的值，最大连接数则是maxConnections的值。 由于BIO和NIO底层实现的区别，配置maxConnections的值也需要区别考虑，这在maxConnections的默认值中就有所体现（对于BIO，maxConnections的默认值是maxThreads的值；而对于NIO，maxConnections的默认值则是10000）： 3 上面有提到，tomcat接收处理请求的过程其实就是一个生产者-消费者模型，影响tomcat高并发的配置也可以首先分别从这两个方面考虑： 生产者 消费者 Queue 4 小结一下： 线程池的本质就是节省了不断创建销毁线程的开销；加上queue的使用，增加了一层缓冲，一定程度缓解了计算机的压力。当然线程池的配置，需要根据要处理的任务（CPU密集型还是io密集型）来仔细的考虑。 Tomcat里面BIO和NIO的最大区别在于读取下一个请求时是否需要阻塞，这对于keep-alive的场景尤其重要，NIO可以大大提高吞吐量。 基于queue的生成者-消费者模型，也常常应用在系统架构层面，以缓冲生产者和消费者之间处理速度的gap，比如秒杀系统。 本文分享自微信公众号 - 天马行空布鲁斯（gh_2feda5c053bd）。如有侵权，请联系 support@oschina.cn 删除。本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
2020-10-26

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

时间: 2025-12-03 大小: 4.36MB 下载: 23次
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2025-12-12 大小: 211.28KB 下载: 54次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2025-12-21 大小: 189MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-03-02 大小: 1.42GB 下载: 3次
热门标签
SpringBoot4 Jdk25 Redis OpenAi Kubernetes Rocky Nacos3 Gemini3 HarmonyOS6 DeepSeek SpringCloud Docker Service Mesh

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册