现在应用系统都使用数据库连接池，Connection关闭并不是物理关闭，只是归还连接池，所以Statement和ResultSet有可能被持有，并且实际占用相关的数据库的游标资源，在这种情况下，只要长期运行就有可能报“游标超出数据库允许的最大值”的错误，导致程序无法正常访问数据库。
针对该类问题建议：
(1) 显式关闭数据库资源，尤其是使用Connection Pool的时候；
(2) 最优经验是按照ResultSet，Statement，Connection的顺序执行close；
(3) 为了避免由于java代码有问题导致内存泄露，需要在rs.close()和stmt.close()后面一定要加上rs = null和stmt = null，并做好异常处理；
(4) 如果一定要传递ResultSet，应该使用RowSet，RowSet可以不依赖于Connection和Statement。
3.2.4JVM优化
针对JVM的参数调整是需要谨慎处理的。常见的JVM参数：
heap参数设置
-server –Xmx1G –Xms1G -Xmn512M-XX ermSize=512M -XX:MaxPermSize=512M -XX:+UseCompressedOops
-server：选择"server" VM，一定要作为第一个参数，与之相对的参数是-client，"client" VM，增加-server参数会影响jvm的其他参数默认值。HotSpot包括一个解释器和两个编译器（client 和 server，二选一的），解释与编译混合执行模式，默认启动解释执行。server启动慢，占用内存多，执行效率高，适用于服务器端应用，JDK1.6以后在具有64位能力的jdk环境下将默认启用该模式； client启动快，占用内存小，执行效率没有server快，默认情况下不进行动态编译，通常用于客户端应用程序或者PC应用开发和调试。
PS：据报道Hotspot的某些版本Servermode被报告有稳定性问题，因此jvm采用server mode还是client mode 需要通过长时间系统监测来评测。
垃圾回收参数设置
-XX:+DisableExplicitGC-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled
-XX:+DisableExplicitGC禁止System.gc()，免得程序员误调用gc方法影响性能；
PS：根据历史经验一般垃圾回收时间占比小于2%则认为对性能影响不大。
日志类参数
-XX:+PrintClassHistogram -XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xloggc:log/gc.log
-XX:+ShowMessageBoxOnError-XX:+HeapDumpOnOutOfMemoryError-XX:+HeapDumpOnCtrlBreak
调试的时候设置一些日志参数，如-XX:+PrintClassHistogram -XX:+PrintGCDetails-XX:+PrintGCTimeStamps -Xloggc:log/gc.log，这样可以从gc.log里查看gc频繁程度，根据此来评估对性能的影响。
调试的时候设置异常宕机时产生heap dump文件，-XX:+ShowMessageBoxOnError-XX:+HeapDumpOnOutOfMemoryError -XX:+HeapDumpOnCtrlBreak，这样可以查看宕机时系统执行哪些操作。
性能监控类参数设置
-Djava.rmi.server.hostname=Server IP-Dcom.sun.management.jmxremote.port=7091-Dcom.sun.management.jmxremote.ssl=false-Dcom.sun.management.jmxremote.authenticate=false
增加以上参数既可以通过visualVM或jconsole监控远程JVM的执行情况。 |
