最近有个用户量 5W-10W 的 web 应用，频繁导致 weblogic 崩溃，让运维组很难受。

   通过几天跟踪系统日志和 weblogic 运行状况，发现报错的姿势有很多，其中对定位问题比较关键的报错：

ExecuteThread: '496' for queue: 'weblogic.kernel.Default (self-tuning)' has beenbusy for "712" seconds working on the request "XXXX", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.

   weblogic 分配给 web 应用使用的线程响应返回周期最大为10分钟，线程迟迟无法返回结果导致阻塞，并且这样的刺头线程越来越多。

   运行一段时间后达到 weblogic 阻塞线程的阀值，weblogic 自然就崩溃了。

   刚开始也试着调大 weblogic 响应周期/阻塞线程的阀值，但是阻塞线程还是会存在并且很快达到阀值。

   仔细比对奔溃前后日志，查看 weblogic 阻塞线程详情，导致阻塞开始罪魁祸首是数据库查询需要很长时间。

   该系统与内外围很多厂商系统有进行数据交互，数据库里面旁根错杂的 db_link/synonyms/view/procedure。

   而且是老旧项目，代码经过很多人修改，已经风烛残年摇摇欲坠，俺想重造它不是一天两天了，因为很多原因无法进行，很无奈。

   规范数据库中的交互流程？然后动代码？oh,no! 限定解决的期限将至，不能拖。

   所有最后将目光放到数据库连接池这部分，也使我不得不重新审视这块对于 web 项目的重要性。好了，言归正传。

回到顶部

1. DataSource / ConnectionPool /  JNDI 三者关系

   DataSource：数据源是在 JDBC2.0 中引入的一个概念；

   在 JDBC 扩展包中定义了Java.sql.DataSource 接口，它负责建立与数据库的连接；

   在应用程序访问数据库是不必编写连接数据库的代码，可直接从数据源获得数据库连接。

   ConnectionPool ：在数据源中初始化建立了多个数据库连接，这些数据库连接保存在连接池（ConnectionPool）中。

   Java程序访问数据库时，只需从连接池中取出空闲状态的数据库连接，当访问结束时，将数据库连接返回给连接池。

   JNDI : （Java Naming and Directory Interface）Java命名与目录接口；

   为开发人员提供了查找和访问各种命名和目录服务的通用、统一的接口。

   其实可以将 JNDI 理解为一种对象和名字绑定的技术，即指定一个资源名称，将该名称与某一资源或服务相关联。

   结合图和上面的简述，数据层关键性对象都已展露无遗，同样也很容易理解。

   JNDI 避免了程序与数据库之间的紧耦合，使应用更加易于配置、易于部署。

回到顶部

2. 配置 JNDI 数据源的方式和使用

   weblogic 上配置 JNDI 为图形界面，操作起来很方便，而且那是运维组的事情，术业有专攻。

   这里我拿 Tomcat 为例（开发时你也不可能在本机装个 weblogic 调试吧），简述下配置 JDNI 的几种方式：

a. 全局使用：Tomcat 的 conf 文件夹下的 context.xml  配置文件中添加：

b.局部使用：Tomcat 的 conf 文件夹下 server.xml 的 标签内添加:

Context path="/demo_jndi" docBase="/demo_jndi">  
     

 c.局部使用：应用 META-INFO 下新建 context.xml 添加：

   上述几种配置使用的数据源都为 javax.sql.DataSource，当然你也可以引入其他开源的数据源。

   也就是 web 容器使用其他的开源数据库连接池，比如像下面这集中姿势（记得将依赖的 jar 添加到容器的 lib 中）：

   配置好之后，使用起来也是相当的简单，核心如下2行代码即可：

    Context ctx = new InitialContext();  
    DataSource ds = (DataSource) ctx.lookup("java:comp/env/jndi/db_test");

   如果项目中引入了 Spring 上述两行代码都可以省了，变动注入数据源配置，如下：