一. 背景
17年公司有个项目组在南京做项目的时候，开发框架用的是spring boot ，数据库连接池用的是druid，但老是遇到socket read timeout的错误，不得已放弃了druid而改用了tomcat数据库连接池，问题得到解决，也就没有深入找druid的原因了（按理说牛掰的druid不应该啊）。
时间到了18年，我所在的项目组到了安徽马鞍山，其中接口平台项目（SpringBoot动态配置多数据源-从数据库读取连接信息）居然也遇到了这个问题（这个项目已在多个地市正常使用，难道是由于马鞍山跟南京挨得太近被传染了吗！），程序动不动就阻塞几十分钟（时间不定），造成客户端长时间等待来一个报错消息。这次我们没有回避这个问题，无论如何要搞定它。
二. 解决问题
巧的是我们的合作公司，他们的项目已经上线一年多了，经常是隔个几天也遇到这个问题，他们的做法是重启整个项目（这样客户体验真的好吗？？？不能苟同啊）。我先是调试了程序，发现就是在运行connection = druidDataSource.getConnection();这句代码（从数据库连接池取一个连接）的时候，程序就阻塞在这里不动了，我把问题拿到网上搜索了一番，初步怀疑是下面两个原因之一：
网络抖动（网络不稳定、闪断）造成的（因为我在使用svn同步项目的时候，经常由于网络问题同步失败）；
防火墙把我的socket连接断开了（因为我的应用服务器和数据库服务器之间有一个防火墙）。
针对原因1，我按照网上的说法（https://blog.csdn.net/supper10090/article/details/79622397?utm_source=blogxgwz3）做了配置，可惜问题还健在。所以我就怀疑是原因2（https://www.2cto.com/database/201505/402016.html）了，找来防火墙的安装公司一查，人家说并没有这个配置。。。大写的尴尬。一不小心进入了小小的迷茫。。。在我静一静之后，找到了这篇文章：https://www.cnblogs.com/trust-freedom/p/6992952.html，在文章的最后，发现了契机，各位小伙伴自己去读读吧，能学到不少东西！
最终，我结合原因1与2的解决方式，得出问题解决办法：
第一步：druidDataSource.setConnectionProperties("oracle.net.CONNECT_TIMEOUT=6000;oracle.jdbc.ReadTimeout=30000"); //后面的ReadTimeout单位也是毫秒，不要设置的太短，否则有些sql执行时间本来就长，报错会影响正常使用
第二步：
druidDataSource.setMinEvictableIdleTimeMillis(180000); //配置一个连接在池中最小生存的时间，单位是毫秒，这里配置为3分钟180000
druidDataSource.setKeepAlive(true); //打开druid.keepAlive之后，当连接池空闲时，池中的minIdle数量以内的连接，空闲时间超过minEvictableIdleTimeMillis，则会执行keepAlive操作，即执行druid.validationQuery指定的查询SQL，一般为select * from dual，只要minEvictableIdleTimeMillis设置的小于防火墙切断连接时间，就可以保证当连接空闲时自动做保活检测，不会被防火墙切断
socket超时导致程序阻塞的问题再也没有出现！以上我是通过代码实现的，大家可以通过配置文件实现。
PS: 对于直接把数据源写死在项目中，这个问题出现的频率不高（但会出现），但由于我的项目数据源是动态配置的，这个问题出现的特别频繁（为什么这么频繁呢？我也不知道了）