使用技巧：Java EE性能问题解决手册7

　　除了线程池数量太小之外的情况外，环境也可能把线程数量配置的过大。当这些环境中的负载量不断增大的时候，CPU的使用率会持续无法降低，就没有什么响应请求的时间了，因为CPU只顾的在众多的线程之间来回的切换跳动，没时间让线程去做他们应该做的事了。

　　连接池过大的最主要的迹象就是CPU的使用率一直很高。有些时候，垃圾收集也可能导致CPU使用率很高，但是垃圾收集导致的CPU使用率很高和池过大导致的使用率有一个主要的区别就是:垃圾收集引起的只是短时间的高使用率就象个钉子，而池过大导致的就是一直持续很高呈线性。

　　这个情况发生的时候，请求会被放在队列中不被处理，但是不会始终如此，因为请求占用CPU的情况和程序占用的情况造成的后果不同。降低线程池的大小可能会让请求等待，但是让请求等待总比为了处理请求而让CPU忙不过来的好。让CPU保持持续的高使用率，同时性能不降低，新请求到来的时候放入到队列中，这是最理想的程序。考虑下面这个很类似的情况:很多高速公里有交通灯来保证车辆进入到拥挤的公里中。在我看来，这些交通灯根本没用，道理很充分。比如你来了，在交通灯后面的安全线上等待进入到高速公路上。如果所有的车辆都同时涌向公里，我们就动弹不得，但是只要减缓涌向高速公路车辆的速度，交通迟早会畅通。事实上，很多的大城市都有这样功能，但根本没用，他们真正需要的是一些更多的小路(CPU)，涌向高速公路的速度真的降低了，那么交通会变的正常起来。

　　设置一个饱和的池，然后逐步减少连接池大小，一直到CPU占用率为75%到85%之间，同时用户负载正常。如果等待队列大小实在无法控制，考虑下面2中建议:

• 　　1.把你的程序放入代码模拟器运行，调整程序代码
• 　　2.增加额外的硬件

　　如果你的用户负载超过了环境能承受的范围，你应该考虑修正代码减少和CPU的冲突或者增加CPU。

　　JDBC连接池

　　很多JAVA EE 程序连接到一个后台数据源，大多数是通过JDBC(JAVA DATABASE CONNECTIVITY)将程序和后台连接起来。由于创建数据库连接的代价很高，程序服务器让在同一个程序服务器实例下的所有程序共享特定数量的一些连接。如果一个请求需要连接到数据库，但是数据库的连接池无法为这个请求创建一个新连接，这个时候请求就会停下来等待连接池完成自己的操作再给她分配一个连接。反过来，如果数据库连接池太大程序服务器就会浪费资源，并且程序有可能强迫数据库承受过量的负荷。我们调试的目的就是尽量减少请求的等待时间和饱和的资源之间之间的冲突，让一个请求在数据库外等待要比强迫数据库好的多。

　　一个程序服务器如果设置连接的数量不合理就会有下面这些特征:

• 　　1.程序运行速度缓慢
• 　　2.CPU使用率低
• 　　3.数据库连接池使用率非常高
• 　　4.线程等待数据库的连接
• 　　5.线程使用率很高
• 　　6.请求队列中有待处理的请求(潜在的)
• 　　7.数据库CPU使用率很低(因为没有足够的请求能够让他繁忙起来)
  　JDBC prepared statements

  　　和JDBC相关的另一个重要的设置就是:为JDBC使用的statement 所预设的缓存的大小。当你的程序在数据库中运行SQL statement 的时候三下面3个步骤进行:

  • 　　1.准备
  • 　　2.执行
  • 　　3.返回数值

  　　在准备阶段，数据库驱动器让数据库完成队列中的执行计划。执行的时候，数据库执行语句并返回指向结果的引用。在返回的时候，程序重新描述这些结果并描述出这些被请求的信息。

  　　数据库驱动会这样优化程序:首先，你需要去准备一个statement ，这个statement 它会让数据库做好执行和缓存结果的准备。在此同时，数据库驱动会从缓存中装载已经准备好的statement ，而不用直接连接到数据库。

  　　如果prepared statement 设置太小，数据库驱动器会被迫去查询没有装载进缓存区的statement ，这就会增加额外的连接到数据库的时间。prepared statement 缓存区设置不恰当最主要的症状就是花费大量的时间去连接相同的statement。这段被浪费的时间本来是为了让它去装载后面的调用的。

  　　事情变的稍微复杂了点，缓存prepared statement 是每个statement的基础，就是说在一个statement连接之前都应当缓存起来。这个增加的复杂性就产生了一个冲突:如果你有100个prepared statement需要去缓存，但你的连接池中有50个数据库连接，这个时候你就需要有存放5000条预备语句的内存。

  　　通过跟踪性能，确定出你程序所执行的不重复的statement 的数量，并从这些statement 中找出哪些条是频繁执行的。

  　　Entity bean(实体BEAN)和stateful session bean的缓冲

  　　无状态(stateless)对象可以被放入到池中共享，但象Entity beans和 stateful session bean这样的有状态的对象就需要被缓存，因为这些bean的每个实例都是不相同的。当你需要一个有状态对象时，你需要明确创建这个对象的特定实例，普通的实例是不能满足的。类似的，你考虑一个超市类似的情况，你需要个售货员但他叫什么并不重要，任何售货员都可以满足你。也就是，售货员被放入池中共享，因为你只需要是售货员就可以，而不是一个叫做史缔夫的这个售货员。当你离开超市的时候，你需要带上你的孩子，不是其他人的孩子，而是你自己的。这个时候，孩子就需要被缓存。