服务器环境8核 32G内存
问题：
在5000个连接的时候Tomcat内存基本吃满
Tomcat 压测：
连接数
内存消耗
CPU
1000
6.9G
100%
2000
12G
100%
3000
19G
100%
4000
25G
100%
4468
30G
100%
更多连接已经无法建立
检查下JVM内存使用情况，其中老年代被占用了98.4%，有大量不能释放的对象在heap。
老年代内存大小31.5G，老年代使用31G
JETTY压测
连接数
内存消耗
CPU
1000
1G
25%
3000
1G
25%
5000
1.1G
25%
10000
1.2G
25%
20000
1.4G
50%
内存情况老年代被使用了79.4%，老年代总大小3.5G占用0.5G
通过现象我们可以看到jetty占用内存非常小，而TOMCAT暂用却非常多，但是国外论坛有人Tomcat却可以压到4万的连接，是什么东西占用了这么多heap空间呢?
分析TOMCAT内存占满原因：
一，由于测试方便在本地启动程序建立了501个连接，并且用jmap生成了快照
二，我们用mat来分析下内存的情况(也可以用jhat，但是太low了很多还需要人工肉眼看和计算)
我们可以看到WsFrameServer占用了2.9的heap空间对象个数恰好是我们建立的连接数
三，现在我们来分析WsFrameServer对象，到底什么东西可以占用这么大
我们可以看到WsFrameServer对象直接引用对象的heap空间HeapCharBuffer和HeapByteBuffer非常大
我们再来看看这个大对象什么引用在引用，通过分析我们知道了原来是WsFrameServer的messageBufferText成员变量
下面我们来看下源代码
我们在WsFrameServer的父类中发现了这两个大对象的引用
那么问题来了，是什么原因导致这个对象很大的呢？我们继续看源代码什么地方用来它，特别是初始化的时候
我们检查到，这个地方初始化的，初始化大小是wsSession.getMaxBinaryMessageBufferSize()
和wsSession.getMaxTextMessageBufferSize()，那么问题又来了，这两个值有是从哪里来的呢？
我们查看源码
有一个默认值是8K，如果是8K的话内存不至于溢出，看什么地方做了赋值
原来是这个地方做的赋值，那么webSocketContainer又是从哪里来的呢？
我们点进去
这里要么是默认值，要么是什么地方做了设置我们打断点调试，而且这个默认值是8K，肯定是什么地方修改了，那么我们在set方法打断点
断点来了，我们通过线程栈来分析下什么地方调到这里来的，跟着往上点
最后我们发现是这个类ServletServerContainerFactoryBean，这个类是spring提供的，我们是在这儿用到了，原来如此，内存之所以这么大就是这里的设置导致的，这个设置的目的是让websocket可以传输更大的消息
其实我们看到的Tomcat的webSocketContainer是实现了javax.websocket.webSocketContainer的，很明显这个是J2EE的规范我们可以查下这个规范
其实这个类就是在初始化的时候可以让你设置websocket相关的一些参数
但是它设置了之后对所有session都生效了所以导致我们的连接数上不去，有什么办法可以解决吗，我们查到有另外的J2EE规范可以在运行过程中动态的修改而且是针对特定session的
那么问题来了，为什么jetty没有出现这个问题，如果是J2EE的规范那么我们设置这个值JETTY也应该出现这个问题，可是没有！
我们再来对jetty进行调试，发现这个配置对jetty不起作用
为什么不起作用呢？这又是另外的问题了~
后来通过源码分析得知JETTY和TOMCAT的实现不一样，不知道算不算BUG，个人认为是JETTY的BUG~
什么代码实现导致他们不一样呢？
Tomcat每次请求过来时在创建session时都会把这个webSocketContainer作为参数传进去所以对所有的session都生效了
我们来看看jetty
启动初始化时jetty把webSocketContainer的参数值设置给了这个过滤器，我们看看这个过滤器它的dofilter方法
其实在这个过滤器我们没有注册任何的访问URL，因为我们是通过spring提供的方式实现的websocket，如果我们在这个过滤器注册了访问URL那么所有过来的请求都会生效~可以继续跟后面的代码，其实就是调用的其他处理器来处理，这些处理器是在这里初始化的
每个url都有一个单独的处理器，这个实现是springboot提供的
spring给每一个websocket URL单独new 了一个处理器，jetty里面这个类是WebSocketServerFactory
其实jetty的处理方式是事件驱动模式设计，把所有的请求当做一个事件，不同的事件有自己对应的eventdriver来处理
重点是jetty在实例化这个对象的时候并没有把webSocketContainer所带的参数设置进去
这就导致了Tomcat生效jetty没有生效，其实你还会发现虽然jetty的buffer默认大小是64K，Tomcat是8K，可是jetty压测的时候CPU和内存都比Tomcat少，这是为什么呢？
原因是jetty用了对象池，不像tomcat来一次请求就new一个buffer，下面是jetty使用对象池的地方
后面简单做了netty的压测10000个连接消耗内存190M，吊炸天的存在

数据库连接池可能很多人一直不明白真正的作，也无法真实的体会其明显的作用，
很多初级开发者可能大我都是用完就close了，要用时就打开，这是否对小的应用来说
用不用连接池效果不是很明显，还有一点就是初级开发者常常不记得关闭连接，使得
数据库服务器被连接占满，同时连接池因设定了最大连接数，而可能使得超过了连接时
数据库无法使用。有可能很多开发者因为以前用asp,php,vb等的原因，好像不关闭连接也没什么影响
但在J2EE中，数据库连接不关闭后果很严重。
  我们来看看数据连接耗时操作。
  1）分析URL连接参数，包括协议、IP地址、端口等的分析与验证。并分板URL成为参数，如把协议，DATABSE，userName,passWord等从中分出来放入Hashtable中
  2）注删及加载驱动
  3）在注册的驱动列表中查找能使用的驱动，一般驱动管理员会一个个驱动去试，驱动通过分析URL是否为自己URL。如果是返回true
  4）驱动用传入的参数实例化继承自Connection的对象，产生Connection实例。
  5）和URL指定的数据库服务器进行SOCKET连接，进行网络数据传输握手。
  6）登录数据库服务器，创建statement及resultSet,并设置语言环境及数据格式.
  7）完成初台化工作，返回Connection对象。

  很显然一次连接要做上面主要的7个部分的操作，部分操作还比较耗时。当然测试中发现一段建立一个连接的耗时为几百毫秒，快时也有几十毫秒。
  频率比较少的访问问题不大，但是访问量很大时，耗时就非常明显，大测试发现用连接池去执行sql语句几乎不耗时间的。

  连接是不是必需的，只是在访问量比较大时确实能省很多的时间，提高效率，但在访问题很少的情况下，也能提高数据的操作效率，同时节省数据库
  的连接开销。

  那么连接池怎么实现的呢？连接池的最少应实现那些功能。
  1）连接在使用后不应马上关闭，可能后面其它程式还要使用。
  2）保留一个最小活动连接，使其程式不需要在建立连接时消耗时间，活动连接，可以在初始化时首先建立，也可以在连接中回收。
  3）最大连接数，连接池中的连接最大不超过这个数，这样做也是避免把数据连接耗完，通常这样的问题是因为程式没有写好的原因。
  4）处理超时连接，也就是连接超过多长时间被认为过期，然后从连接池中清除。
  5）重写Connection的close方法，因为哪不重写，将会使用户使用close方法时真正关闭连接，而不是放入连接池。

  其实连接池也比较简单，主要是实现上面几个需求。如tomcat的连接池实现类就是为：
  org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper

  因此连接池的逻辑为：
  1）取连接时，先到连接池中找，如果没有空闭的连接，而又没有超过最大连接数，建一个新的连接。
  	 如果超过了抛出异常。
  2）得到连接后，连接池减少1
  3）使用完后如果连接池没有超过最大连接数放入连接池，超过直接关闭。
  4）如果加入连接池的连接，连接池计数+1
  5）时间监听连接是否超时，如果超时将关闭，从连接池中-1，直到最后只有最少的活动连接数。

  这里我们有一个问题，连接池是怎么知道连接是否超过最大连接呢，有些连接在使用，他们在连接池中并没有计数，也就是说他们取出后计数器
  就-1了。，事实上我们可以用另一个记录正在使用的连接，如果用完就从中-1，也可以不去管在使用的连接，我们只用去管空闭的连接就行。
  应该我们设置连接池的最大连接数应是指空闭的最大连接数，而并非空闭连接数+正在使用的连接数。

  还要注意的一点是，连接池的列表应常驻内存，不然用完了就退出内存了，那前池子又要重建立，因此存入连接的对象应是static类型的。

出现以上ORA错误是因为连接数和会话数满导致的。这样的情况下连sqlplus都登录不进去了。由于超过连接最大值导致无法登录，首先需要先断开占用的procress，即停掉所有tomcat释放连接，接下来就可以登录了。如果还是不行，我这里是直接把数据库主机断网，再通过system用户登录sqlplus看一下procress和session的参数值和占用值： 

sqlplus;
SQL> show parameter processes;

SQL> select count(*) from v$process;

SQL>select count(*) from v$session;

SQL> alter system set processes=500 scope=spfile;

SQL> alter system set sessions=500 scope=spfile;

根据需要修改完记得重启ORACLE两个服务才生效。

线上的tomcat服务，昨天用户说无法访问，重启过一次，今天客户又反馈说不能访问，登录到服务器上观察，tomcat内存占用不高，看日志输出tomcat里面跑的java程序并没有死掉，故障现象就是简单的客户端浏览器无法访问服务端口，经过一番查找后，最后通过netstat -an | more 查看，某个IP有大量的绑定到tomcat服务端口的连接，原因就是这些连接把tomcat服务线程数给占满了，继续分析故障原因，是客户端程序里面的apache httpclient 连接程序用完了以后没有关闭连接造成的。