数据库连接池

1.内存泄露指应用程序使用内存后因为错误或者异常导致系统无法将不再使用的内存回收重新分配，致使系统特来越卡，甚至崩溃宕机
2.一般jdbc连接一次消耗很大，耗时0.5-1s，如果通过简单jdbc连接，无法控制连接数，并发很大时建立很多连接，容易宕机
3.数据库连接池，设计模式为资源池，目的是解决连接资源频繁被分配释放的问题，防止系统与数据库无限制连接
4.连接池中连接数目一致，用一个remove一个，用完之后再将连接add回来
5.连接池中connection连接的分配和释放，使用空闲池管理，将已建立未分配的放空闲池，请求连接时先检查空闲池有无连接，有则分配，没有则检查当前连接是否最大，是最大则等待，timeout之后返回null，没有达到最大，则新建一个连接
6.最大最小连接数，最小连接数服务器启动时要建立，这个数字大则启动慢，但启动后响应快，这个数字小则启动快，但之后响应慢
7.tomcat默认使用的是啊、spring提供的dbcp连接，对应两个jar包：common-dbcp.jar和common-pool.jar
8.JNDI、DBCP、jdbc概念区别：
jdbc java database connection 是java提供执行sql语句的api
DBCP database connection pool是数据库连接池，专门管理数据库库连接资源的分配回收释放等
https://www.cnblogs.com/lsdb/p/7151779.html
9.yss使用的是c3p0连接池，将资源池配置在dataSource中，参考
https://blog.csdn.net/z69183787/article/details/22783189
10.连接泄露时，基本就是连接不释放造成的,如果查到v$session中inactive长时间占用不降低，则基本确定是有泄露
11.查询各台机器的连接数，https://blog.csdn.net/tylz04/article/details/9041775#

select b.MACHINE, b.PROGRAM , count(b.status) from v$process a, v$session b where a.ADDR = b.PADDR and b.USERNAME is not null group by b.MACHINE , b.PROGRAM order by b.status       desc, count(*) desc;
---最大连接数
select value from v$paramter where name='processes'

----当前连接数
select count(*) from v$process
---

12。oracle中v$session和v$process的字段讲解，
v$session中各个字段的讲解
https://www.cnblogs.com/haizine/p/6209833.html
https://blog.csdn.net/haiross/article/details/17718383

13.查询长时间占用sql，（可能查不出来东西）

select logon_time,
       last_call_et "time inactive",
       nvl(s.username, 'ORACLE PROCESS') username,
       s.program,
       s.sid session_id,
       s.status,
       sql_text,
       ss.value "CPU used",
       trunc(buffer_gets / (executions + 1)) "BUFF-EXEC",
       trunc(buffer_gets / (rows_processed + 1)) "BUFF-ROWS",
       first_load_time,
       executions,
       parse_calls,
       disk_reads,
       buffer_gets,
       rows_processed
  from v$session s, v$sesstat ss, v$statname sn, v$sqlarea sa
 where s.sid = ss.sid
   and ss.statistic# = sn.statistic#
   and sn.name = 'CPU used by this session'
   and s.sql_address = sa.address
   and s.sql_hash_value = sa.hash_value
   ----and last_call_et > 1000
 order by machine, status, program, last_call_et asc;

14.查询未活跃状态session对应的上次执行的sql

select a.status,a.osuser,b.sql_text,b.sql_fulltext from v$session a,v$sqlarea b 
where a.status='inactive' and a.prev_sql_id = b.sql_id and a.osuser='ex_kjkfzx_zhangsx'

15 inactive的含义
该状态处于等待操作(即等待需要执行的SQL语句)，通常当DML语句已经完成。 但连接没有释放，这个可能是程序中没有释放，如果是使用中间件来连接的话，也可能是中间件的配置或者是bug 导致。
16.连接池泄露的问题最大的可能就是连接未关闭，spring框架中，基本就是spring事务没有生效，目前发现有两种原因，交给spring的bean在其他地方被new了一个，二是xml文件中没有配置事务
17.dbcp的一些简单配置
https://blog.csdn.net/zys_1997/article/details/78107783

	<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
		<property name="url" value="${url}" />
		<property name="username" value="${username}"/>
		<property name="password" value="${password}"/>
		<property name="driverClassName" value="${driverClassName}"/>
		<property name="initialSize" value="1" />
		<property name="maxActive" value="5" />
		<property name="maxIdle" value="1" />
		<property name="maxWait" value="10000" />
		<!--空闲连接的释放时间，超过这个时间将被释放-->
		<property name="minEvictableIdleTimeMillis" value="10000" />
		<!--5秒检查一次连接池的空闲连接是否有超时-->
		<property name="timeBetweenEvictionRunsMillis" value="5000" />
		<!-- 验证使用的SQL语句-->
		<property name="validationQuery" value="SELECT 1 from dual" />
	</bean>