linux连接池 java数据库连接池
在Linux上查看活跃线程数与连接数
如今，线程池与连接池已经成为Java后端程序的常见配置。这些资源对程序至关重要，一旦不足，可能导致程序阻塞和性能下降。因此，了解它们的使用情况，以判断是否存在瓶颈，变得尤为必要。
在Linux上，使用top-H-p 1命令可以查看java进程的线程情况，其中1是java进程号。通过此命令，可以看到线程的名称、CPU使用率等信息。例如，http-nio-8080-e就是Tomcat线程池中的线程。需要注意的是，Linux中线程名称存在长度限制，可能会被截断。
对于JDK8及以上版本，需要达到jdk8u222以上版本，才能在top中查看线程名称。通过数一下http-nio-8080-e线程的数量，可以发现它与springboot中的线程配置相匹配。
要了解线程池的使用情况，即活跃线程数量，可以使用top命令的-i选项，配合sed/awk/uniq等文本处理命令统计。这样，就可以得到活跃线程数。例如，在20个线程的线程池中，1秒内只有4个线程是活跃的，说明线程池中线程数量是足够的。
在Linux上，使用ss-natp|grep pid=1可以查看1号进程的TCP连接。例如，若redis数据库端口是6379，则可以查看redis连接池中的连接数量。要了解活跃连接数量，可以使用awk过滤出lastsnd或lastrcv小于1000的tcp连接，这些连接即为1秒内活跃过的连接。
此外，arthas工具也是一个不错的选择。它的vmtool命令可以获取指定类型的Java对象，并从中获取信息。例如，使用vmtool工具获取tomcat线程池的活跃情况，可以调用线程池的getActiveCount()等方法获取活跃线程数。
高并发的MySQL数据查询时,会不会选择数据库连接池
现象
Sysbench对MySQL进行压测,并发数过大(>5k)时, Sysbench建立连接的步骤会超时.
猜想
猜想:直觉上这很简单, Sysbench每建立一个连接,都要消耗一个线程,资源消耗过大导致超时.
验证:修改Sysbench源码,调大超时时间,仍然会发生超时.
检查环境
猜想失败,回到常规的环境检查:
MySQL error log未见异常.
syslog未见异常.
tcpdump观察网络包未见异常,连接能完成正常的三次握手;只观察到在出问题的连接中,有一部分的TCP握手的第一个SYN包发生了重传,另一部分没有发生重传.
自己写一个简单的并发发生器,替换sysbench,可重现场景.排除sysbench的影响
猜想2
怀疑 MySQL在应用层因为某种原因,没有发送握手包,比如卡在某一个流程上:
检查MySQL堆栈未见异常,仿佛MySQL在应用层没有看到新连接进入.
通过strace检查MySQL,发现accept()调用确实没有感知到新连接.
怀疑是OS的原因, Google之,得到参考文档:A TCP“stuck” connection mystery【】
分析
参考文档中的现象跟目前的状况很类似,简述如下:
正常的TCP连接流程:
Client向 Server发起连接请求,发送SYN.
Server预留连接资源,向 Client回复SYN-ACK.
Client向 Server回复ACK.
Server收到 ACK,连接建立.
在业务层上, Client和Server间进行通讯.
当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie,变为:
Client向 Server发起连接请求,发送SYN.
Server不预留连接资源,向 Client回复SYN-ACK,包中附带有签名A.
Client向 Server回复ACK,附带 f(签名A)(对签名进行运算的结果).
Server验证签名,分配连接资源,连接建立.
在业务层上, Client和Server间进行通讯.
当启用SYN-cookie时,第3步的ACK包因为某种原因丢失,那么:
从Client的视角,连接已经建立.
从Server的视角,连接并不存在,既没有建立,也没有”即将建立”(若不启用SYN-cookie, Server会知道某个连接”即将建立”)
发生这种情况时:
若业务层的第一个包应是从 Client发往 Server,则会进行重发或抛出连接错误
若业务层的第一个包应是从 Server发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.
TCP握手的第三步ACK包为什么丢失
参考文档中,对于TCP握手的第三步ACK包的丢失原因,描述为:
Some of these packets get lost because some buffer somewhere overflows.
我们可以通过Systemtap进一步探究原因.通过一个简单的脚本:
probe kernel.function("cookie_v4_check").return
{
source_port=@cast($skb->head+$skb->transport_header,"struct tcphdr")->source
printf("source=%d, return=%d\n",readable_port(source_port),$return)
}
function readable_port(port){
return(port&((1<<9)-1))<< 8|(port>> 8)
}
观察结果,可以确认cookie_v4_check(syn cookie机制进行包签名检查的函数)会返回 NULL(0).即验证是由于syn cookie验证不通过,导致TCP握手的第三步ACK包不被接受.
之后就是对其中不同条件进行观察,看看是哪个条件不通过.最终原因是accept队列满(sk_acceptq_is_full):
static inline bool sk_acceptq_is_full(const struct sock*sk){ return sk->sk_ack_backlog> sk->sk_max_ack_backlog;}
恢复故障与日志的正关联
在故障处理的一开始,我们就检查了syslog,结论是未见异常.
当整个故障分析完成,得知了故障与syn cookie有关,回头看syslog,里面是有相关的信息,只是和故障发生的时间不匹配,没有正关联,因此被忽略.
检查Linux源码:
if(!queue->synflood_warned&&
sysctl_tcp_syncookies!= 2&&
xchg(&queue->synflood_warned, 1)== 0)
pr_info("%s: Possible SYN flooding on port%d.%s.
Check SNMP counters.\n",
proto, ntohs(tcp_hdr(skb)->dest), msg);
可以看到日志受到了抑制,因此日志与故障的正关联被破坏.
粗看源码,每个listen socket只会发送一次告警日志,要获得日志与故障的正关联,必须每次测试重启MySQL.
解决方案
这种故障一旦形成,难以检测;系统日志中只会出现一次,在下次重启MySQL之前就不会再出现了; Client如果没有合适的超时机制,万劫不复.
解决方案:
1.修改MySQL的协议,让Client先发握手包.显然不现实.
2.关闭syn_cookie.有安全的人又要跳出来了.
3.或者调高syn_cookie的触发条件(syn backlog长度).降低系统对syn flood的敏感度,使之可以容忍业务的syn波动.
有多个系统参数混合影响syn backlog长度,参看【】
下图为精华总结
请点击输入图片描述
golang连接池管理tcp
Golang网络编程丝绸之路-TCP/UDP地址解析
TL;DR在使用Golang编写TCP/UDPsocket的时候，第一步做的就是地址解析。
该函数返回的地址包含的信息如下：
TCPAddr里，IP既可以是IPv4地址，也可以是IPv6地址。Port就是端口了。Zone是IPv6本地地址所在的区域。
从返回结果看该函数的参数，network指address的网络类型；address指要解析的地址，会从中解析出我们想要的IP,Port和Zone。
从源码中可以看出，参数network只能是如下四个值，否则会得到一个错误。
解析过程跟ResolveTCPAddr的一样，不过得到的是*UDPAddr。
UDPAddr包含的信息如下：
【golang】高并发下TCP常见问题解决方案
首先，看一下TCP握手简单描绘过程：
其握手过程原理，就不必说了，有很多详细文章进行叙述，本文只关注研究重点。
在第三次握手过程中，如果服务器收到ACK，就会与客户端建立连接，此时内核会把连接从半连接队列移除，然后创建新的连接，并将其添加到全连接队列，等待进程调用。
如果服务器繁忙，来不及调用连接导致全连接队列溢出，服务器就会放弃当前握手连接，发送RST给客户端，即connectionresetbypeer。
在linux平台上，客户端在进行高并发TCP连接处理时，最高并发数量都要受系统对用户单一进程同时打开文件数量的限制（这是因为系统每个TCP都是SOCKET句柄，每个soker句柄都是一个文件），当打开连接超过限制，就会出现toomanyopenfiles。
使用下指令查看最大句柄数量：
增加句柄解决方案
一篇搞懂tcp，http，socket，socket连接池之间的关系
作为一名开发人员我们经常会听到HTTP协议、TCP/IP协议、UDP协议、Socket、Socket长连接、Socket连接池等字眼，然而它们之间的关系、区别及原理并不是所有人都能理解清楚，这篇文章就从网络协议基础开始到Socket连接池，一步一步解释他们之间的关系。
首先从网络通信的分层模型讲起：七层模型，亦称OSI(OpenSystemInterconnection)模型。自下往上分为：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。所有有关通信的都离不开它，下面这张图片介绍了各层所对应的一些协议和硬件
通过上图，我知道IP协议对应于网络层，TCP、UDP协议对应于传输层，而HTTP协议对应于应用层，OSI并没有Socket，那什么是Socket，后面我们将结合代码具体详细介绍。
关于传输层TCP、UDP协议可能我们平时遇见的会比较多，有人说TCP是安全的，UDP是不安全的，UDP传输比TCP快，那为什么呢，我们先从TCP的连接建立的过程开始分析，然后解释UDP和TCP的区别。
TCP的三次握手和四次分手
我们知道TCP建立连接需要经过三次握手，而断开连接需要经过四次分手，那三次握手和四次分手分别做了什么和如何进行的。
第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，SequenceNumber为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置AcknowledgmentNumber为x+1(SequenceNumber+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，SequenceNumber为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK报文段。然后将AcknowledgmentNumber设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。通信结束客户端和服务端就断开连接，需要经过四次分手确认。
第一次分手：主机1（可以使客户端，也可以是服务器端），设置SequenceNumber和AcknowledgmentNumber，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，AcknowledgmentNumber为SequenceNumber加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；
第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
可以看到一次tcp请求的建立及关闭至少进行7次通信，这还不包过数据的通信，而UDP不需3次握手和4次分手。
TCP和UDP的区别
1、TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的可靠性;而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议。
2、也正由于1所说的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。知道了TCP和UDP的区别，就不难理解为何采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了，但并不能说QQ的通信是不安全的，因为程序员可以手动对UDP的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，即使是这样，UDP因为在底层协议的封装上没有采用类似TCP的“三次握手”而实现了TCP所无法达到的传输效率。
关于传输层我们会经常听到一些问题
1．TCP服务器最大并发连接数是多少？
关于TCP服务器最大并发连接数有一种误解就是“因为端口号上限为65535,所以TCP服务器理论上的可承载的最大并发连接数也是65535”。首先需要理解一条TCP连接的组成部分：客户端IP、客户端端口、服务端IP、服务端端口。所以对于TCP服务端进程来说，他可以同时连接的客户端数量并不受限于可用端口号，理论上一个服务器的一个端口能建立的连接数是全球的IP数*每台机器的端口数。实际并发连接数受限于linux可打开文件数，这个数是可以配置的，可以非常大，所以实际上受限于系统性能。通过#ulimit-n查看服务的最大文件句柄数，通过ulimit-nxxx修改xxx是你想要能打开的数量。也可以通过修改系统参数：
2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的Socket可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
3．TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态会产生什么问题
通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态，TIME_WAIT状态维持时间是两个MSL时间长度，也就是在1-4分钟，Windows操作系统就是4分钟。进入TIME_WAIT状态的一般情况下是客户端，一个TIME_WAIT状态的连接就占用了一个本地端口。一台机器上端口号数量的上限是65536个，如果在同一台机器上进行压力测试模拟上万的客户请求，并且循环与服务端进行短连接通信，那么这台机器将产生4000个左右的TIME_WAITSocket，后续的短连接就会产生addressalreadyinuse:connect的异常，如果使用Nginx作为方向代理也需要考虑TIME_WAIT状态，发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决。
编辑文件，加入以下内容：
然后执行/sbin/sysctl-p让参数生效。
net.ipv4.tcp_syncookies=1表示开启SYNCookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse=1表示开启重用。允许将TIME-WAITsockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle=1表示开启TCP连接中TIME-WAITsockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout修改系统默认的TIMEOUT时间
相关视频推荐
10道网络八股文，每道都很经典，让你在面试中逼格满满
徒手实现网络协议栈，请准备好环境，一起来写代码
学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
需要C/C++Linux服务器架构师学习资料加qun812855908获取（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享
关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：“我们在传输数据时，可以只使用(传输层)TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容。如果想要使传输的数据有意义，则必须使用到应用层协议。应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。
HTTP协议即超文本传送协议(HypertextTransferProtocol)，是Web联网的基础，也是手机联网常用的协议之一，WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。
由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。
下面是一个简单的HTTPPostapplication/json数据内容的请求：
现在我们了解到TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket。现在我们知道，Socket跟TCP/IP并没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以，Socket的出现只是可以更方便的使用TCP/IP协议栈而已，其对TCP/IP进行了抽象，形成了几个最基本的函数接口。比如create，listen，accept，connect，read和write等等。
不同语言都有对应的建立Socket服务端和客户端的库，下面举例Nodejs如何创建服务端和客户端：
服务端：
服务监听9000端口
下面使用命令行发送http请求和telnet
注意到curl只处理了一次报文。
客户端
Socket长连接
所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接(心跳包)，一般需要自己做在线维持。短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接。比如Http的，只是连接、请求、关闭，过程时间较短,服务器若是一段时间内没有收到请求即可关闭连接。其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。
通常的短连接操作步骤是：
连接数据传输关闭连接；
而长连接通常就是：
连接数据传输保持连接(心跳)数据传输保持连接(心跳)……关闭连接；
什么时候用长连接，短连接？
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成Socket错误，而且频繁的Socket创建也是对资源的浪费。
什么是心跳包为什么需要：
心跳包就是在客户端和服务端间定时通知对方自己状态的一个自己定义的命令字，按照一定的时间间隔发送，类似于心跳，所以叫做心跳包。网络中的接收和发送数据都是使用Socket进行实现。但是如果此套接字已经断开（比如一方断网了），那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。其实TCP中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那TCP就会在一定的时间（比如你设置的是3秒钟）内发送你设置的次数的心跳（比如说2次），并且此信息不会影响你自己定义的协议。也可以自己定义，所谓“心跳”就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”,以确保链接的有效性。
实现：
服务端：
服务端输出结果：
客户端代码：
客户端输出结果：
如果想要使传输的数据有意义，则必须使用到应用层协议比如Http、Mqtt、Dubbo等。基于TCP协议上自定义自己的应用层的协议需要解决的几个问题：
下面我们就一起来定义自己的协议，并编写服务的和客户端进行调用：
定义报文头格式：length:000000000xxxx;xxxx代表数据的长度，总长度20,举例子不严谨。
数据表的格式:Json
服务端:
日志打印：
客户端
日志打印：
客户端定时发送自定义协议数据到服务端，先发送头数据，在发送内容数据，另外一个定时器发送心跳数据，服务端判断是心跳数据，再判断是不是头数据，再是内容数据，然后解析后再发送数据给客户端。从日志的打印可以看出客户端先后writeheader和data数据，服务端可能在一个data事件里面接收到。
这里可以看到一个客户端在同一个时间内处理一个请求可以很好的工作，但是想象这么一个场景，如果同一时间内让同一个客户端去多次调用服务端请求，发送多次头数据和内容数据，服务端的data事件收到的数据就很难区别哪些数据是哪次请求的，比如两次头数据同时到达服务端，服务端就会忽略其中一次，而后面的内容数据也不一定就对应于这个头的。所以想复用长连接并能很好的高并发处理服务端请求，就需要连接池这种方式了。
什么是Socket连接池,池的概念可以联想到是一种资源的集合，所以Socket连接池，就是维护着一定数量Socket长连接的集合。它能自动检测Socket长连接的有效性，剔除无效的连接，补充连接池的长连接的数量。从代码层次上其实是人为实现这种功能的类，一般一个连接池包含下面几个属性：
场景：一个请求过来，首先去资源池要求获取一个长连接资源，如果空闲队列里面有长连接，就获取到这个长连接Socket,并把这个Socket移到正在运行的长连接队列。如果空闲队列里面没有，且正在运行的队列长度小于配置的连接池资源的数量，就新建一个长连接到正在运行的队列去，如果正在运行的不下于配置的资源池长度，则这个请求进入到等待队列去。当一个正在运行的Socket完成了请求，就从正在运行的队列移到空闲的队列，并触发等待请求队列去获取空闲资源，如果有等待的情况。
这里简单介绍Nodejs的Socket连接池generic-pool模块的源码。
主要文件目录结构
下面介绍库的使用：
初始化连接池
使用连接池
下面连接池的使用，使用的协议是我们之前自定义的协议。
日志打印：
这里看到前面两个请求都建立了新的Socket连接socket_pool127.0.0.19000connect，定时器结束后重新发起两个请求就没有建立新的Socket连接了，直接从连接池里面获取Socket连接资源。
源码分析
发现主要的代码就位于lib文件夹中的Pool.js
构造函数：
lib/Pool.js
可以看到包含之前说的空闲的资源队列，正在请求的资源队列，正在等待的请求队列等。
下面查看Pool.acquire方法
lib/Pool.js
上面的代码就按种情况一直走下到最终获取到长连接的资源，其他更多代码大家可以自己去深入了解。
Golang建立TCP时使用连接池
程序输出如下，相比不用连接池，单次操作时间少了一个数量级。
Golang需要自己实现数据库连接池吗
使用完后必须con.close()掉，
使用连接池的话，执行con.close并不会关闭与数据库的TCP连接，而是将连接还回到池中去，如果不close掉的话，这个连接将会一直被占用，直接连接池中的连接耗尽为止。
golang获取tcp连接的文件描述符fd
有个通过代理进来的tcp连接，通过Conn.RemoteAddr获取到的是代理点的ip地址，为了获取实际客户端的ip，找到了syscall.Getpeername的方法，而这个方法需要的是连接的fd。
