一个detect问题引发的一系列思考

在用BoneCP的时候，发现一个JVM日志中报了一个异常，大意是“探测（detect）到有数据库链接没有关闭”（不得不说JVM的强大），但是我用的是连接池里面的链接啊，怎么会需要关闭呢？

有问题首先找官网。

于是我上官网又看了一遍Demo，但是只是一个简单的Demo，历史的BoneCP的sample的链接都没有了（Server Internal Exception）当时也没有多想，后文会有解释。根据Demo来看用完之后确实close了，而且fianlly里面连整个连接池都关闭了；所以讲他只是个Demo，只是描述了在使用一次情况下的处理。

官网解决不了google。

而且最好是中文搜索，BoneCP connection close；果然，第一个就是stackoverflow里面的人提问。点机一看，里面点赞最多的一个回答需要关闭，但是Connection的关闭并不会关闭物理连接，只是将链接还回了缓冲池，读到这里，我恍然大悟，一致看到Connection就以为是原生的Connection，看到close就以为是关闭物理连接。我想到了在debug代码的时候，缓冲池返回的connection其实是ConnectionHandle，当时心理曾经闪过一丝困惑，这里明白了，结果之前看到的源码Connection其实就是一个interface；但是你通过Driver获取的Connection则是一个代理，这个代理的close可是会真切的关闭链接。

看到网上的答案后，还要验证一下。

之前和汪洋有一个乌龙，我们讨论了一下Cloudera里面spark的agent的作用，我是一个论坛上看到过一个回帖，说是agent就是cloudera magager的一个埋点，用于监控服务；于是我坚持agent就是监测埋点；但是汪洋则说他们在实际部署的时候发现只有部署了spark agent才能够执行spark-submit；后来我问了一个cloudera内部人员，他的解释和汪洋是一样。

所以，网上获得答案后，一定要找别的渠道再验证一下。于是我看了一下BoneCP的源码，确实close函数里面没有半毛钱的关闭链接，只是修改了一些列的状态，应该就是在连接池中标记该链接是free的。

沟通，交流。

我觉这次调研还是有意义的，毕竟觉得看到close，到最后才发现其实close并不是想象的样子“你看到的，未必是你看到的样子”，我简单的描述了一下调研过程，发到了朋友圈。一个之前的同事回复了一句：为什么不用durid？其实Jeesite里面的缓冲池配置的就是Druid，当时没太在意；之前没用过。

这个朋友圈发出去之后，确实有收获，之前一直纠结要不要再朋友圈曝光，今天这番事件，应验了老罗曾经说的：一件事情说不好做还是不做，那就做，可能会有意外收获。

扩展，关于深度和广度

保持对技术的敏感度，其实那个同事建议后，我便尝试了解一下Druid以及BoneCP，看到了一篇很好的文章讲述这些缓冲池的历史，其中降到了BoneCP其实已经被作者放弃了，因为他又开发了一个更加高速的缓冲池。看到此处我不禁汗颜，因为官网已经去过，但是并没有注意这些事情，我再二次去网站的时候才看到他的最后一次更次年log是在2013年，去了github的挂网看到了下面的一段话：

BoneCP is a Java JDBC connection pool implementation that is tuned for high performance by minimizing lock contention to give greater throughput for your applications. It beats older connection pools such as C3P0 and DBCP but SHOULD NOW BE CONSIDERED DEPRECATED in favour of HikariCP

.我觉得研究一个技术除了技术本身，比如技术机制之外，如果是你关注的你还要关注几个维度，活跃度，受欢迎程度，代码质量。通过一些途径比如官网，github等来对于这个技术的周边进行了解。就像李红光关注操场草坪一样，因为这些都是会加深你对于这个产品的了解，就像搞对象要从各个渠道来了解一样；所以，研究技术就要想找媳妇一样。

上面说的是深度，再就是广度，当初看到了jeesite配置里面的Druid其实应该研究一下才对，这样将会对于你有更加宽泛的选择。