1、过量的数据库调用
问题：常见的性能瓶颈来自过量的数据库调用，引发这些问题不一定是SQL查询的Execute（）或Update（），而是应用程序与数据库的交互有关，例如，ResultSet操作，常见的问题是指定了过于精细的查询条件，然后使用ResultSet.Next（）详细搜寻返回的数据。
解决办法：从数据库中大量取得所要求的数据，避免应用程序反复回掉数据库。
2、数据库连接池问题
问题1：连接池资源泄露。
虽然可以通过WebLogic自带工具、Jprofiler工具或自编工具检测到数据库连接池资源泄露，但是很难再应用程序代码本身准确定位泄露的源头。
解决办法：仔细分析程序代码，是否没有close（）连接？是否遗漏了finally块？或者尽管有close（）但并没有成功。
问题2：连接池大小。
连接池过小会导致连接池满后，新的客户无法连接上系统，在日志中出现错误信息。一般的解决方法是增大连接池。但另一方面，连接池过大会造成资源无效损耗，可能会出现新的性能问题。那么连接池调到多大比较合适呢？
解决办法：
经验法则1：设置最初池大小=最大池大小。
经验法则2，数据库连接池数=线程池数*每个线程需要连接数据库的平均数*1.1（1.1的含义是增加10%的峰值期负载），通常每个线程需要连接数据库的平均数是1，即当线程数为120时，数据库连接池数就是132.
3、SQL语句及其索引或锁定属性问题
问题：SQL语句及其索引或锁定属性不合理可能引发DISKIO过忙（磁盘读/写数据）或者CPU过忙（在内存中索引排序），造成执行时间过长，阻塞线程的执行，最终引发系统挂起或者执行超时引发系统挂起。
解决方法：优化SQL语句及其索引或锁定属性。