首先从代码层面上,相信有编写数据库经验的同学已经发现jdbc中冗余代码过多,也就是复用性差,比如下面笔者曾经多次看不下去但又没了解优化时写的代码:
再来从宏观上看看这样的代码产生的问题:
你会发现当用户使用我们应用程序时,每个业务都会产生对数据库的多次直接操作,这样是十分很耗性能,每次数据库的打开和关闭都浪费大量的时间,所以终于有了牛逼的
连接池和ThreadLocal
正因为我们需要规避应用程序直接操作数据库,所以我们需要借助连接池
来存储应用程序需要打开的数据库连接:这样就避免了时间的损耗:
会发现,通过各种连接池我们只需要通过第一次打开数据库,就可以获得该数据库的所有连接,放置在一个数据源里 这样以后程序发出的任何业务请求连接 都会从连接池中拿去,从而和数据库解耦合
这个是第三方jar ,所以使用前一定要引入
commons-dbcp-1.4.jar, commons-poor.jar
由于代码很简洁,极力推荐使用
/**
* dbcp连接池 - 配置文件方式
* @return
* @throws Exception
*/
public static Connection getConnectionByDBCPFactory() throws Exception{
javax.sql.DataSource ds = BasicDataSourceFactory.createDataSource(prop);
return ds.getConnection();
}
简单来说: 通过借助上面两个jar 引入了一个BasicDataSourceFactory对象,他是DataSource的子类也就是说,任何连接池都可以通过各自实例化DataSource对象来获取
至于参数prop
这个采用了配置文件方式,如果没用过可以看看配置文件
刚才仅仅解决了应用程序直接操作数据库的问题, 但是使用连接池又不可避免引入一个效率问题: 值得注意的是:
由于连接池处理的量有限,于是ThreadLocal应用而生,他的原理是:
通俗的说,计算机自带crtl+c 明白了吧
具体实现:
也需要依赖一个jar : commons-dbutils-1.4.jar
private static ThreadLocal<Connection> threadLocal = new ThreadLocal<>();
public static Connection getConnection() throws Exception{
Connection connection = threadLocal.get();
if(connection == null){
//第一条连接 需要手动创建
connection = DBUtils.getConnectionByDBCPFactory();
threadLocal.set(connection);
}
return connection;
}
长得很像单例 ,所以任何业务需要用到连接直接通过getConnection调用,不过需要注意的是记得不用Threadlocal时,关闭connection资源
直接调用remove方法就行
这又是因为笔者一次偷懒举动产生的一次数据库优化,未来还得继续偷懒.啦啦啦… 各位仙友加油吧 奥利给