面试官:如何实现一个连接池,我当场懵了

共 4475字,需浏览 9分钟

 ·

2021-03-27 18:28


  点击上方“JavaEdge”,关注公众号

设为“星标”,好文章不错过!

什么是连接池?





结构


连接池对外提供如下接口:

  • 获得连接

  • 归还连接

暴露最小空闲连接数、最大连接数等客户端可配置的参数

对内则实现如下功能:

  • 连接建立

  • 连接心跳保持

  • 连接管理

  • 空闲连接回收

  • 连接可用性检测

连接池结构示意图


若客户端SDK没有使用连接池,而直接是TCP连接,就需要考虑每次建立TCP连接的开销。因为TCP基于字节流,多线程下对同一连接操作有线程安全隐患。

TCP连接的客户端SDK,对外提供API方式




连接池和连接分离式


有一个XXXPool类负责连接池实现:

  1. 先从其获得连接XXXConnection

  2. 再用所获连接请求服务端

  3. 完成后归还连接

XXXPool必须是线程安全的,可并发获取和归还连接,而XXXConnection是非线程安全的。
对应到连接池结构示意图,XXXPool就是右边连接池那个框,左边客户端是我们自己的代码。

最佳实践


连接池本身一般是线程安全的,可复用。每次使用需要从连接池获取连接,使用后归还,归还的工作由使用者负责。



内置连接池


对外提供一个XXXClient类,通过该类可直接请求服务端。该类内部维护了连接池,SDK使用者无需考虑连接的获取和归还问题。
XXXClient是线程安全的。对应到连接池结构示意图中,整个API就是蓝框。

最佳实践


大多数中间件、数据库的客户端SDK都会支持连接池,SDK负责连接的获取和归还,使用的时候直接复用客户端。



非连接池


一般命名为XXXConnection,以区分其是基于连接池or单连接,而不建议命名为XXXClient。直接连接方式的API基于单一连接,每次使用都需要创建和断开连接,性能一般,且通常不是线程安全的。对应到连接池的结构示意图中,这种形式相当于没有右边连接池那个框,客户端直接连接服务端创建连接。

最佳实践


那通常不是线程安全的,而且短连接的方式性能不会很高,使用的时候需要考虑是否自己封装一个连接池。

Jedis属于哪种呢?



多线程环境下复用一个连接会发生什么?

首先,向Redis初始化2组数据,Key=a、Value=1,Key=b、Value=2:

@PostConstructpublic void init() {    try (Jedis jedis = new Jedis("127.0.0.1", 6379)) {        Assert.isTrue("OK".equals(jedis.set("a", "1")), "set a = 1 return OK");        Assert.isTrue("OK".equals(jedis.set("b", "2")), "set b = 2 return OK");    }}

然后,启动两个线程,共享操作同一个Jedis实例,每一个线程循环1000次,分别读取Key为a和b的Value,判断是否分别为1和2:

Jedis jedis = new Jedis("127.0.0.1", 6379);new Thread(() -> {    for (int i = 0; i < 1000; i++) {        String result = jedis.get("a");        if (!result.equals("1")) {            log.warn("Expect a to be 1 but found {}", result);            return;        }    }}).start();new Thread(() -> {    for (int i = 0; i < 1000; i++) {        String result = jedis.get("b");        if (!result.equals("2")) {            log.warn("Expect b to be 2 but found {}", result);            return;        }    }}).start();TimeUnit.SECONDS.sleep(5);

执行多次,发现日志各种异常都有:

//错误1[14:56:19.069] [Thread-28] [WARN ] [.t.c.c.redis.JedisMisreuseController:45  ] - Expect b to be 2 but found 1//错误2redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream.  at redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:202)  at redis.clients.jedis.util.RedisInputStream.readLine(RedisInputStream.java:50)  at redis.clients.jedis.Protocol.processError(Protocol.java:114)  at redis.clients.jedis.Protocol.process(Protocol.java:166)  at redis.clients.jedis.Protocol.read(Protocol.java:220)  at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:318)  at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:255)  at redis.clients.jedis.Connection.getBulkReply(Connection.java:245)  at redis.clients.jedis.Jedis.get(Jedis.java:181)  at org.geekbang.time.commonmistakes.connectionpool.redis.JedisMisreuseController.lambda$wrong$1(JedisMisreuseController.java:43)  at java.lang.Thread.run(Thread.java:748)//错误3java.io.IOException: Socket Closed  at java.net.AbstractPlainSocketImpl.getOutputStream(AbstractPlainSocketImpl.java:440)  at java.net.Socket$3.run(Socket.java:954)  at java.net.Socket$3.run(Socket.java:952)  at java.security.AccessController.doPrivileged(Native Method)  at java.net.Socket.getOutputStream(Socket.java:951)  at redis.clients.jedis.Connection.connect(Connection.java:200)  ... 7 more

让我们分析一下Jedis类的源码,搞清楚其中缘由吧。





BinaryClient封装了各种Redis命令

都是调用其父类Connection方法,使用Protocol类发送命令

Protocol类的sendCommand方法

发送命令时是直接操作RedisOutputStream写字节。

在多线程环境下复用Jedis对象,其实就是在复用RedisOutputStream。如果多个线程在执行操作,那么既无法确保整条命令以一个原子操作写入Socket,也无法确保写入后、读取前没有其他数据写到远端。
这就能解释了为何多线程下使用Jedis对象操作Redis会出现各种问题:

  • 写操作互相干扰,多条命令交织,必然是非法的Redis命令,则Redis会关闭客户端连接,导致连接断开

  • 线程1和2先后写入get a和get b请求,Redis也返回了值1和2,但是线程2先读取了数据1就会出现数据错乱的问题。




修复


使用Jedis提供的线程安全的类JedisPool来获得Jedis的实例。JedisPool作为连接池,可以声明为static 被多线程共享。注意使用try-with-resources模式。
这样使用后代码不再有线程安全问题。最好再通过shutdownhook,在程序退出之前关闭JedisPool:

@PostConstructpublic void init() {    Runtime.getRuntime().addShutdownHook(new Thread(() -> {        jedisPool.close();    }));}


Jedis#close


若Jedis是从连接池获取的话,则close方法会调用连接池的return方法归还连接:

如果不是,则直接关闭连接,其最终调用Connection类的disconnect方法来关闭TCP连接:

可见Jedis可独立使用,也可配合连接池(JedisPool)

JedisPool





JedisPool继承JedisPoolAbstract又继承抽象类Pool,Pool内部持有Apache Common的GenericObjectPool。


所以JedisPool的连接池其实就是直接复用的GenericObjectPool,并没有自己实现一套池子。

综上,Jedis API属于连接池和连接分离的API,JedisPool是线程安全的连接池,Jedis是非线程安全的单一连接。


往期推荐


由于不知线程池的bug,某Java程序员叕被祭天

程序员因重复记录日志撑爆ELK被辞退!

拥抱Kubernetes,再见了Spring Cloud

JDK为何自己先破坏双亲委派模型?




目前交流群已有 800+人,旨在促进技术交流,可关注公众号添加笔者微信邀请进群


喜欢文章,点个“在看、点赞、分享”素质三连支持一下~

浏览 41
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报