问题四：数据库连接池不释放
搭e6mall需要使用tomcat7搭建。
过程：压测一个商品的详情页请求，看看报错如何？按照上面方法分析
1、先访问tomcat的初始页面，可以访问，这说明：tomcat负载机、网络、tomcat连接池，tcp/ip没有问题。
2、接下来看 cpu ，top：没问题。
]# top top - 18:54:44 up 8 days, 6:55, 3 users, load average: 0.00, 0.00, 0.00 Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2054084k total, 1817816k used, 236268k free, 186872k buffers Swap: 0k total, 0k used, 0k free, 833836k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1178 root 10 -10 123m 9.9m 5456 S 0.3 0.5 47:35.04 AliYunDun 1884 root 20 0 221m 9.9m 5064 S 0.3 0.5 2:29.35 docker 9136 root 20 0 2587m 316m 16m S 0.3 15.8 0:41.86 java
3、线程栈以及 jvm 都没问题，问题在哪？
4、我们看下数据库连接池，发现连接池很多被 e6mall 占用，但是 sleep 了，我们可以看到有 30 个连接池被占用了(ip和db都要符合规则）。
数据库连接池：
1、数据库本身对外提供的连接池的最大数（数据库配置文件里的）
2、应用程序配置的客户端和服务器建立的连接数（项目里配置的）
数据库连接池不释放，【数据库连接一般用完立即释放，配置90个连接就算很高了，单机配四五十就算挺高了】
开始配置30个连接，都被用掉了，后来改为90也被用完了，所以这里是数据库连接池不释放导致的问题。
之前我们有提到过，数据库连接池除了在数据库内部设置最大连接数，在程序内也有，我们的数据库最大连接数查询命令为：show variables like '%max_connections%';并且可以查到，是 151 个。接下来我们去程序中查看数据库的属性连接。
我们的最大连接数一般是在配置文件内，去 e6mall 内查看 jdbc.properties：（xxx为我的 ip）
jdbc.driverClassName=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://xx.xxx.xxx.xxx:3306/e6mall?useUnicode=true&characterEncoding=utf-8&autoReconnect=true&zeroDateTimeBehavior=round jdbc.username=root jdbc.password=123456
可以看到只有基础的属性配置，但是没有详细的连接配置，我们的 dangdang 是有的，那么这里在哪配的呢？
e6mall/WEB-INF/classes/applicationContext.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:jdbc.properties</value>
</list>
</property>
</bean>
<bean id="velocityEngine" class="org.springframework.ui.velocity.VelocityEngineFactoryBean">
<property name="velocityProperties">
<props>
<prop key="resource.loader">class</prop>
<prop key="class.resource.loader.class">
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
</prop>
<prop key="velocimacro.library"></prop>
</props>
</property>
</bean>
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
<property name="driverClass" value="${jdbc.driverClassName}" />
<property name="jdbcUrl" value="${jdbc.url}" />
<property name="user" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
<!--连接池中保留的最小连接数。 -->
<property name="minPoolSize">
<value>5</value>
</property>
<!--连接池中保留的最大连接数。Default: 15 -->
<property name="maxPoolSize">
<value>30</value>
</property>
<!--初始化时获取的连接数，取值应在minPoolSize与maxPoolSize之间。Default: 3 -->
<property name="initialPoolSize">
<value>10</value>
</property>
<!--最大空闲时间,60秒内未使用则连接被丢弃。若为0则永不丢弃。Default: 0 -->
<property name="maxIdleTime">
<value>60</value>
</property>
<!--当连接池中的连接耗尽的时候c3p0一次同时获取的连接数。Default: 3 -->
<property name="acquireIncrement">
<value>5</value>
</property>
<!-- JDBC的标准参数，用以控制数据源内加载的PreparedStatements数量。但由于预缓存的statements 属于单个connection而不是整个连接池。所以设置这个参数需要考虑到多方面的因素。
如果maxStatements与maxStatementsPerConnection均为0，则缓存被关闭。Default: 0 -->
<property name="maxStatements">
<value>0</value>
</property>
<!--每60秒检查所有连接池中的空闲连接。Default: 0 -->
<property name="idleConnectionTestPeriod">
<value>60</value>
</property>
<!--定义在从数据库获取新连接失败后重复尝试的次数。Default: 30 -->
<property name="acquireRetryAttempts">
<value>30</value>
</property>
<!-- 获取连接失败将会引起所有等待连接池来获取连接的线程抛出异常。但是数据源仍有效 保留，并在下次调用getConnection()的时候继续尝试获取连接。如果设为true，那么在尝试
获取连接失败后该数据源将申明已断开并永久关闭。Default: false -->
<property name="breakAfterAcquireFailure">
<value>false</value>
</property>
<!-- 因性能消耗大请只在需要的时候使用它。如果设为true那么在每个connection提交的 时候都将校验其有效性。建议使用idleConnectionTestPeriod或automaticTestTable
等方法来提升连接测试的性能。Default: false -->
<property name="testConnectionOnCheckout">
<value>false</value>
</property>
</bean>
说明最大连接数我配了 30 ，就连上了 30 ，初步判断是数据库连接池不释放，那么怎么验证？我们把 30 改成 120 再压测，如果数据库连接池又被占满了，则可以判断是连接池不释放导致的。
果然，120个又被占满，说明是数据库连接池不释放导致的问题
总结
根据问题现象，去定位问题。具体方式是根据我们的架构拓扑图去排查，有些是经验推断，以及日志内的分析去定位大致范围。还有比较重要的能定位问题的：日志内的埋点的时间信息。在日志内打印接口的调用时间。如果响应时间长，在日志内打出来接口的调用时间，再减去数据库内发生的时间，就是接受请求之前所花费的时间。
还有超时问题，503问题，响应超时，web容器处理慢，数据库超时； 502：超时，大叔总结。
以及频繁gc的问题。
性能监控和企业分析的ppt，查看案例。