前言

Minidao害惨了我，我差一点就要被项目经理抬去祭天，还好发现了这个问题，就在这里记录一下吧！

我只是单纯的重视一下这种事情，这是我一个人的观点，不代表全部观点，但是这是我真真实实遇到并且存在的问题！

我们系统有一个微信推送消息，每天推送数量不定，有的时候多，有的时候少，我们的数据库连接池采用Durid，连接数最大为500。 每次推送告警我们都发现数据库连接数在500左右，基本上是全部沾满了。

后来我们再数据库连接上修改配置，但是起到的作用微乎其微，所以就把矛头指向了当时开发时候使用的一个数据库操作开源插件Minidao，当时使用版本是1.5.1，因为系统中，使用了minidao之后，很多地方对于单表的增删改查不需要书写SQL，还是挺爽的，开发速度是快了，当时后面带出了祭天的风险啊！

问题简述

连接池泄露问题

这里输入引用文本由于项目中使用了minidao 1.5.1，hibernate的增删改查不需要书写sql语句的地方造成程序运行的时候出现了连接池泄露，数据库连接数一直在300以上。

对于此事我进行测查看源码和测试。

正道

我在这里还是要注明一下：我用的版本是1.5.1，现在最新版本1.6.3，不是解决了这个问题，而是没有了那个类，是我看错了？所以我记录下。

所以我就踏上了测试Minidao之路！

1、书写测试代码

2、执行前数据库连接数

3、执行后数据库连接数

4、minidao源代码

这些测试说明了，使用xxxByHiber的进行数据库操作都会差生一个连接，并且不会关闭。

 //*********************test source(数据库中字段设置很小所以抛异常)******************         for (int i = 0; i < 50; i++) { 		BI_DIM bi_DIM = new BI_DIM(); 		if(i > 20)                             bi_DIM.setBiz_Table_Name("123====================================================================="+i); 		else 			bi_DIM.setBiz_Table_Name("123===="+i); 		bi_DIM.setDim_Name("测试"); 		bi_DIM.setDrill_Info(""); 		try { 			dimDao.saveByHiber(bi_DIM); 		} catch (Exception e) { 		        System.err.println("抛异常了"+i+"; info:"+e.getMessage()); 		} 	} 	return "";         //**********************minidao source********************************************         /** 	 * 根据传入的实体持久化对象 	 */ 	public <T> void save(T entity) { 		try { 			getSession().save(entity); 			getSession().flush(); 			if (logger.isDebugEnabled()) { 				logger.debug("保存实体成功," + entity.getClass().getName()); 			} 		} catch (RuntimeException e) { 			logger.error("保存实体异常", e); 			getSession().close(); 			throw e; 		}  	}

我觉得你们肯定不可能没有发现！ 请问关于minidao 1.5.1版本的，连接池泄露问题是怎么解决的呢？

此问题，是一个非常不严谨的错误了！

minidao 1.5.1 源码​github.com

码云代码仓库地址

 蚁点 andot.org

本人只是阐述观点！