问题描述：
生产数据库（oracle）中的session数量超高（2500以上），严重影响该库的性能。
原因：weblogic的数据库连接池参数配置不符合目前XX应用程序的实际情况，调整weblogic配置参数后，问题
解决。
后续优化：采用线程池取代目前的多线程无限新建的操作。
具体问题分析如下：
问题定位：
1：查看v$session中的2000多个连接，大部分都是Inactive状态，即非活动的，而且都是JDBC调用。
从而猜测这些连接应该是应用程序调用了一次，执行完sql后没有关闭物理连接造成的。
2：通过v$session和v$sqlarea表查看v$session中logon_time集中的区间段内所执行的sql，最后定位到两条:
select 1 from dual和insert XX_web…._log …..(这条具体sql忘了，就是XX系统记录操作日志的那条sql)
经过和开发人员的沟通从而定位到这条sql的调用时XX系统中的激活等相关接口的实现程序。
问题分析：
XX系统的激活相关接口由于有些是大批量的调用，而且每一条都需要记录日志到数据库，为了保障效率，程序中
采用了多线程处理激活逻辑和记录日志操作。
查看了XX的相关代码，数据库操作都是走的appframe的统一连接获取和关闭操作，没有程序员自己新建数据库
连接和未关闭的情况。从而猜测是否是appframe框架自己的连接管理出了问题，随后跟踪代码发现appframe的数据库连接
close最终调用的是每个应用自己配置的数据库连接池的close，它自己并不关注底层的connection.close。而且该框架
的应用相当多，这块也很成熟了，应该没有问题，进而进行数据库连接池的问题排查。
XX应用没有使用常见的DBCP连接池，而是采用了weblogic中间件提供的数据库连接池，查看weblogic的monitor
console,显示最高的连接数目2500，和在数据库中查看的session数目一致，但weblogic连接池配置的Maximum Capacity
（最大连接数量）为100，共6个server，也就是说连接池最大能容纳600个连接，为什么最高时会达到2500呢？想到四种可能：
1：weblogic的连接池bug或weblogic的监控台显示bug。2：连接池泄露（这个查看了leaked connection的个数，6个
server均显示0，基本排除该元因）。3：特殊的情况可以不受容量限制。4：weblogic故意的（因为它自己的监控台能查看到这
2000多个连接，证明这些连接肯定还是由它产生并可控）。
1和2基本不太考虑，这么牛的产品应该不会出现这种低级BUG。主要考虑3和4，随后仔细查看了weblogic的connection pool
的参数配置，配合oracle官方文档，突然发现有一个“Pinned-To-Thread”参数比较奇怪，名字中带线程，联想到XX应用程序
正是在多线程的情况下产生的问题，所以仔细研究了该参数的含义，该设置启用后，当application关闭connection后,connection
并不会回到connection pool,而是被keep在thread里,因此假如application在同一个thread又需要使用connection时,可以马上取得
特点：不受限' Maximum Capacity'参数，至此问题就明确了，weblogic利用该参数优化多线程的数据库连接管理，避免高并发时的新建连接
消耗资源，影响性能。但这样就会造成多线程产生的数据库连接不会真正关闭物理连接，而且不它不受Maximum Capacity的限制，
这也就解释了为什么连接池最大数目600，但真实连接能达到2500了。
由于XX的多线程程序未使用线程池，每次都是new一个新的线程，所以当数据库连接池启用Pinned-To-Thread功能后，每新建一个数据库操作的线程，
就会绑死一个数据库物理连接，如果线程无限增长，理论上物理连接也会无限增长。XX的多线程数据库操作特点是执行sql很短，数量很多，
所以只是用大容量的连接池应该就能满足要求，线程执行完立马释放连接回连接池，下一个线程再从连接池取，没必要将连接绑定线程。
将该功能关闭后重启weblogic的server，测试，该问题消失，性能，每秒钟6条业务激活数据减小为4条业务激活数据，可以接受。
后续可以考虑采用线程池来缓存线程重复利用，这样开启Pinned-To-Thread功能后能达到更好的性能，这时的数据库库物理连接数由线程池的线程数目配置决定了。