下面列出一些常见的关于字符串优化的策略，简单的我就不多作解释了。

1) 使用规则表达式处理字符串匹配代替复杂的字符串查找和复制操作；

2) 使用不拷贝字符串中字符的高效方法，例如String.subString()方法；

3) 尽可能不要使用需要拷贝字符串中字符的低效方法，例如String.toUpperCase()和String.toLowercase()；

4) 在编译期使用String的“+”操作符来执行连接操作，在运行期使用StringBuffer执行连接操作；

这里特别强调一下，因为我已经在网上看到好多文章都推荐使用StringBuffer的append()方法来做字符串的连接操作。其实在JVM能够在编译期就能确定结果的情形，使用String的“+”操作符的性能要好很多。

3.3 异常，类型转换和变量

       1) 考虑在抛出异常的时候是否可以不即时生成堆栈信息而使用一个已有的异常实例；

       创建异常的开销很大。当创建一个异常时，需要收集一个栈跟踪（Stack Trace），这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。运行时栈不是为有效的异常创建而设计的，而是设计用来让运行时尽可能快地运行。入栈，出栈，入栈，出栈。让这样的工作顺利完成，而没有任何不必要的延迟。但是，当需要创建一个Exception时，JVM不得不说：“先别动，我想就你现在的样子存一份快照，所以按时停止入栈和出栈操作，笑着等我拍完快照吧。”栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素，从栈顶到栈底，还有行号和一切应有的东西。

       因此，创建异常这一部分开销很大。从技术上讲，栈跟踪快照是在本地方法Throwable.fillInStackTrace()中发生的，这个方法不是从Throwable contructor那里调用的。但是这并并没有什么影响——如果你创建了一个Exception，就得付出代价。好在捕获异常开销不大，因此可以用try-catch将核心内容包起来。你也可以在方法定义中定义throws子句，这样对性能不会造成什么损失。从技术上讲，你甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是throw操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常。

       幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。但是，万一你不想遵从好的编程习惯，Java语言就会让你知道，那样就可以让你的程序运行的更快，从而鼓励你去那样做。

       2) 用instanceof替代在try-catch中做投机的强制类型转换方法；

       3) 尽可能少的使用强制类型转换方法，尤其是使用类型特定的集合类时；

       4) 使用int优先于其他所有的数据类型；

       5) 尽可能使用基本数据类型做临时变量；

       6) 考虑直接获取实例变量而不通过get，set方法获取（注意：这不符合面向对象的封装原则，不推荐使用）。

3.4 循环，选择和递归

       1) 在循环中消除不必要的代码，做尽可能少的事情；

       2) Switch语句中使用连续的case值；

       3) 确定是否真的需要用到递归，最好转为用循环来实现。

3.5 输入输出操作

       1) 在程序中尽量不要使用System.out这样的语句，而使用log4j这样的日志工具替换，以在程序正式上线的时候可以关闭所有不必要的日志操作提高性能；

       2) 当程序中有大量的I/O操作时，考虑将日志写入不同的文件做到并行化操作以提高性能，并可以用一个后台线程执行I/O操作而不打断正常程序的执行；

       3) 正确的使用序列化机制，没有必要序列化的成员变量需要标识为transient；

       4) 使用NIO技术。

3.6 JDBC

       1) 使用正确的JDBC驱动，尽可能地选择最新的JDBC驱动；

       最新的JDBC驱动不仅优化了性能，而且提供了更多的性能更好的接口供开发人员使用。

       2) 使用应用服务器自带的连接池，而不要使用自己的连接池或干脆不用连接池；

       3) 在使用完数据库资源后，需依次关闭ResultSet，Statement和Connection；

       4) 手动控制事务，使用connection.setAutoCommit(false)关闭自动提交，使用executeBatch()进行批量更新；

       5) 业务复杂或者大数据量操作时使用存储过程；

       6) ResultSet.next()极其消耗性能，建议使用RowSet替代ResultSet；

       7) 把所有的字符数据都保存为Unicode，Java以UniCode形式处理所有数据，数据库驱动程序不必再执行转换过程；

       8) 尽可能的优化SQL语句；

       9) 少用join，多用index；

       10) 使用EXPLAIN工具监控SQL语句的执行，以确定瓶颈所在；

11)  不要使用 SELECT * ..., 使用 SELECT Field1, Field1 ...；

12)  通过index获取字段，而不要使用名字去获取，例如resultSet.getString(1) 而不是 resultSet.getString("field1")；

13)  缓存数据，避免重复查询；

14)  考虑使用内存数据库；

15)  调整fetch size进行批量查询；

16)  尽可能的使Java数据类型和数据库类型相匹配，转换数据在匹配不好的数据类型间效率太差；

17) 避免使用低效的metadata调用，尤其是getBestRowIdentifier( ), getColumns( ), getCrossReference( ), getExportedKeys( ), getImportedKeys( ), getPrimaryKeys( ), getTables( ), and getVersionColumns( )；

18)  使用metadata查询减少数据库网络通信量；

19)  使用最低的事务隔离级别；

20)  使用乐观锁机制；

21)  把应用服务器和数据库分散在不同的机器中，性能可能会更好。

3.7 Servlet和JSP

       1) Session的使用；

       应用服务器保存很多会话时，容易造成内存不足，所以尽量减少Session的使用，放置到Session中的对象不应该是大对象，最好是简单的小对象，实现串行化接口。当会话不再需要时，应当及时调用invalidate()方法清除会话。而当某个变量不需要时，及时调用removeAttribute()方法清除变量。当session终止时需要清除不必要的资源，实现HttpSessionBindingListener接口的valueUnbound()方法。

       2) 使用include directive，而不使用include action；

       目前在JSP页面中引入外部资源的方法主要有两种：include directive和include action。Include directive：例如<%@ include file=”copyright.html” %>，该指令在编译时引入指定的资源。在编译之前，带有include指令的页面和指定的资源被合并成一个文件。被引用的资源在编译时就确定，比运行时才确定资源更高效。Include action：例如< jsp:include page=”copyright.jsp” />，该动作引入指定页面执行后生成的结果。由于它在运行时完成，因此对输出结果的控制更加灵活。但是，只有当引用的内容被频繁改变时，或者在对主页面的请求没有出现之前，被引用的页面无法确定时，使用include action才合算。

       3) 对于那些无需跟踪会话状态的jsp，关闭自动创建的会话可以节省一些资源。使用如下page指令： < %@ page session=”false” %>；

       4) 尽量不要把jsp页面定义为单线程，应设置为< %@page isThreadSafe=”true” %>；

       5) 在jsp页面最好使用输出缓存功能，如：< %@page buffer=”32kb” %>；

       6) 在servlet之间跳转时，forward比sendRedirect更有效；

       7) 设置HttpServletResponse缓冲区，如：response.setBufferSize(20000)；

       8) 建议在servlet里使用ServletOutputStream输出图片等对象；

9) 不要使用SingleThreadModel，使Servlet是线程安全的，但是尽可能的减少消耗在同步代码上的时间，使用足够多的servlet去响应用户的请求；

10) 尽可能的使useBean的范围在page范围内；

11)  Servlet的inti()和destroy()或jspInit()和jspDestroy()方法用于创建和删除昂贵的资源，例如缓存对象和数据库连接；

12)  避免使用反向DNS查找；

13)  预编译JSP页面；

14)  尽可能的在客户段校验数据；

15)  禁止自动装载特色防止周期性的装载servlet和jsp。

3.8 EJB

       由于EJB2.0已经很少项目在用了，EJB3.0再成熟一点，我再补充这一部分吧

Java的堆是一个运行时数据区,类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，这些对象通过new、newarray、anewarray和multianewarray等指令建立，但是它们不需要程序代码来显式地释放。一般来说，堆的是由垃圾回收 来负责的，尽管JVM规范并不要求特殊的垃圾回收技术，甚至根本就不需要垃圾回收，但是由于内存的有限性，JVM在实现的时候都有一个由垃圾回收所管理的堆。垃圾回收是一种动态存储管理技术，它自动地释放不再被程序引用的对象，按照特定的垃圾收集算法来实现资源自动回收的功能。

垃圾收集的意义

在C++中，对象所占的内存在程序结束运行之前一直被占用，在明确释放之前不能分配给其它对象；而在Java中，当没有对象引用指向原先分配给某个对象的内存时，该内存便成为垃圾。JVM的一个系统级线程会自动释放该内存块。垃圾收集意味着程序不再需要的对象是"无用信息"，这些信息将被丢弃。当一个对象不再被引用的时候，内存回收它占领的空间，以便空间被后来的新对象使用。事实上，除了释放没用的对象，垃圾收集也可以清除内存记录碎片。由于创建对象和垃圾收集器释放丢弃对象所占的内存空间，内存会出现碎片。碎片是分配给对象的内存块之间的空闲内存洞。碎片整理将所占用的堆内存移到堆的一端，JVM将整理出的内存分配给新的对象。

垃圾收集能自动释放内存空间，减轻编程的负担。这使Java 虚拟机具有一些优点。首先，它能使编程效率提高。在没有垃圾收集机制的时候，可能要花许多时间来解决一个难懂的存储器问题。在用Java语言编程的时候，靠垃圾收集机制可大大缩短时间。其次是它保护程序的完整性, 垃圾收集是Java语言安全性策略的一个重要部份。

垃圾收集的一个潜在的缺点是它的开销影响程序性能。Java虚拟机必须追踪运行程序中有用的对象, 而且最终释放没用的对象。这一个过程需要花费处理器的时间。其次垃圾收集算法的不完备性，早先采用的某些垃圾收集算法就不能保证100%收集到所有的废弃内存。当然随着垃圾收集算法的不断改进以及软硬件运行效率的不断提升，这些问题都可以迎刃而解。

垃圾收集的算法分析

Java语言规范没有明确地说明JVM使用哪种垃圾回收算法，但是任何一种垃圾收集算法一般要做2件基本的事情：（1）发现无用信息对象；（2）回收被无用对象占用的内存空间，使该空间可被程序再次使用。

大多数垃圾回收算法使用了根集(root set)这个概念；所谓根集就量正在执行的Java程序可以访问的引用变量的集合(包括局部变量、参数、类变量)，程序可以使用引用变量访问对象的属性和调用对象的方法。垃圾收集首选需要确定从根开始哪些是可达的和哪些是不可达的，从根集可达的对象都是活动对象，它们不能作为垃圾被回收，这也包括从根集间接可达的对象。而根集通过任意路径不可达的对象符合垃圾收集的条件，应该被回收。下面介绍几个常用的算法。

1、 引用计数法(Reference Counting Collector)

引用计数法是唯一没有使用根集的垃圾回收的法，该算法使用引用计数器来区分存活对象和不再使用的对象。一般来说，堆中的每个对象对应一个引用计数器。当每一次创建一个对象并赋给一个变量时，引用计数器置为1。当对象被赋给任意变量时，引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用)，引用计数器减1，一旦引用计数器为0，对象就满足了垃圾收集的条件。

基于引用计数器的垃圾收集器运行较快，不会长时间中断程序执行，适宜地必须 实时运行的程序。但引用计数器增加了程序执行的开销，因为每次对象赋给新的变量，计数器加1，而每次现有对象出了作用域生，计数器减1。

2、tracing算法(Tracing Collector)

tracing算法是为了解决引用计数法的问题而提出，它使用了根集的概念。基于tracing算法的垃圾收集器从根集开始扫描，识别出哪些对象可达，哪些对象不可达，并用某种方式标记可达对象，例如对每个可达对象设置一个或多个位。在扫描识别过程中，基于tracing算法的垃圾收集也称为标记和清除(mark-and-sweep)垃圾收集器.

3、compacting算法(Compacting Collector)

为了解决堆碎片问题，基于tracing的垃圾回收吸收了Compacting算法的思想，在清除的过程中，算法将所有的对象移到堆的一端，堆的另一端就变成了一个相邻的空闲内存区，收集器会对它移动的所有对象的所有引用进行更新，使得这些引用在新的位置能识别原来 的对象。在基于Compacting算法的收集器的实现中，一般增加句柄和句柄表。　　

4、copying算法(Coping Collector)

该算法的提出是为了克服句柄的开销和解决堆碎片的垃圾回收。它开始时把堆分成 一个对象 面和多个空闲面， 程序从对象面为对象分配空间，当对象满了，基于coping算法的垃圾 收集就从根集中扫描活动对象，并将每个 活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞)，这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。

一种典型的基于coping算法的垃圾回收是stop-and-copy算法，它将堆分成对象面和空闲区域面，在对象面与空闲区域面的切换过程中，程序暂停执行。

5、generation算法(Generational Collector)
　　stop-and-copy垃圾收集器的一个缺陷是收集器必须复制所有的活动对象，这增加了程序等待时间，这是coping算法低效的原因。在程序设计中有这样的规律：多数对象存在的时间比较短，少数的存在时间比较长。因此，generation算法将堆分成两个或多个，每个子堆作为对象的一代(generation)。由于多数对象存在的时间比较短，随着程序丢弃不使用的对象，垃圾收集器将从最年轻的子堆中收集这些对象。在分代式的垃圾收集器运行后，上次运行存活下来的对象移到下一最高代的子堆中，由于老一代的子堆不会经常被回收，因而节省了时间。

6、adaptive算法(Adaptive Collector)

在特定的情况下，一些垃圾收集算法会优于其它算法。基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况，并将选择适当算法的垃圾收集器。

透视Java垃圾回收

1、命令行参数透视垃圾收集器的运行

2、使用System.gc()可以不管JVM使用的是哪一种垃圾回收的算法，都可以请求Java的垃圾回收。在命令行中有一个参数-verbosegc可以查看Java使用的堆内存的情况，它的格式如下：

java -verbosegc classfile

　　可以看个例子：

class TestGC
{
　public static void main(String[] args)
　{
　　new TestGC();
　　System.gc();
　　System.runFinalization();
　}
}

　　在这个例子中，一个新的对象被创建，由于它没有使用，所以该对象迅速地变为可达，程序编译后，执行命令： java -verbosegc TestGC 后结果为：

[Full GC 168K->97K(1984K), 0.0253873 secs]

　　机器的环境为，Windows 2000 + JDK1.3.1,箭头前后的数据168K和97K分别表示垃圾收集GC前后所有存活对象使用的内存容量，说明有168K-97K=71K的对象容量被回收，括号内的数据1984K为堆内存的总容量，收集所需要的时间是0.0253873秒（这个时间在每次执行的时候会有所不同）。

　　2、finalize方法透视垃圾收集器的运行

　　在JVM垃圾收集器收集一个对象之前 ，一般要求程序调用适当的方法释放资源，但在没有明确释放资源的情况下，Java提供了缺省机制来终止化该对象心释放资源，这个方法就是finalize（）。它的原型为：

protected void finalize() throws Throwable

　　在finalize()方法返回之后，对象消失，垃圾收集开始执行。原型中的throws Throwable表示它可以抛出任何类型的异常。

　　之所以要使用finalize()，是由于有时需要采取与Java的普通方法不同的一种方法，通过分配内存来做一些具有C风格的事情。这主要可以通过"固有方法"来进行，它是从Java里调用非Java方法的一种方式。C和C++是目前唯一获得固有方法支持的语言。但由于它们能调用通过其他语言编写的子程序，所以能够有效地调用任何东西。在非Java代码内部，也许能调用C的malloc()系列函数，用它分配存储空间。而且除非调用了free()，否则存储空间不会得到释放，从而造成内存"漏洞"的出现。当然，free()是一个C和C++函数，所以我们需要在finalize()内部的一个固有方法中调用它。也就是说我们不能过多地使用finalize()，它并不是进行普通清除工作的理想场所。

　　在普通的清除工作中，为清除一个对象，那个对象的用户必须在希望进行清除的地点调用一个清除方法。这与C++"破坏器"的概念稍有抵触。在C++中，所有对象都会破坏（清除）。或者换句话说，所有对象都"应该"破坏。若将C++对象创建成一个本地对象，比如在堆栈中创建（在Java中是不可能的），那么清除或破坏工作就会在"结束花括号"所代表的、创建这个对象的作用域的末尾进行。若对象是用new创建的（类似于Java），那么当程序员调用C++的delete命令时（Java没有这个命令），就会调用相应的破坏器。若程序员忘记了，那么永远不会调用破坏器，我们最终得到的将是一个内存"漏洞"，另外还包括对象的其他部分永远不会得到清除。

　　相反，Java不允许我们创建本地（局部）对象--无论如何都要使用new。但在Java中，没有"delete"命令来释放对象，因为垃圾收集器会帮助我们自动释放存储空间。所以如果站在比较简化的立场，我们可以说正是由于存在垃圾收集机制，所以Java没有破坏器。然而，随着以后学习的深入，就会知道垃圾收集器的存在并不能完全消除对破坏器的需要，或者说不能消除对破坏器代表的那种机制的需要（而且绝对不能直接调用finalize()，所以应尽量避免用它）。若希望执行除释放存储空间之外的其他某种形式的清除工作，仍然必须调用Java中的一个方法。它等价于C++的破坏器，只是没后者方便。

　　下面这个例子向大家展示了垃圾收集所经历的过程，并对前面的陈述进行了总结。

class Chair {
　static boolean gcrun = false;
　static boolean f = false;
　static int created = 0;
　static int finalized = 0;
　int i;
　Chair() {
　　i = ++created;
　　if(created == 47)
　　　System.out.println("Created 47");
　}
　protected void finalize() {
　　if(!gcrun) {
　　　gcrun = true;
　　　System.out.println("Beginning to finalize after " + created + " Chairs have been created");
　　}
　　if(i == 47) {
　　　System.out.println("Finalizing Chair #47, " +"Setting flag to stop Chair creation");
　　　f = true;
　　}
　　finalized++;
　　if(finalized >= created)
　　　System.out.println("All " + finalized + " finalized");
　}
}

public class Garbage {
　public static void main(String[] args) {
　　if(args.length == 0) {
　　　System.err.println("Usage: \n" + "java Garbage before\n or:\n" + "java Garbage after");
　　　return;
　　}
　　while(!Chair.f) {
　　　new Chair();
　　　new String("To take up space");
　　}
　　System.out.println("After all Chairs have been created:\n" + "total created = " + Chair.created +
", total finalized = " + Chair.finalized);
　　if(args[0].equals("before")) {
　　　　System.out.println("gc():");
　　　　System.gc();
　　　　System.out.println("runFinalization():");
　　　　System.runFinalization();
　　}
　　System.out.println("bye!");
　　if(args[0].equals("after"))
　　　System.runFinalizersOnExit(true);
　}
}

　　上面这个程序创建了许多Chair对象，而且在垃圾收集器开始运行后的某些时候，程序会停止创建Chair。由于垃圾收集器可能在任何时间运行，所以我们不能准确知道它在何时启动。因此，程序用一个名为gcrun的标记来指出垃圾收集器是否已经开始运行。利用第二个标记f，Chair可告诉main()它应停止对象的生成。这两个标记都是在finalize()内部设置的，它调用于垃圾收集期间。另两个static变量--created以及finalized--分别用于跟踪已创建的对象数量以及垃圾收集器已进行完收尾工作的对象数量。最后，每个Chair都有它自己的（非static）int i，所以能跟踪了解它具体的编号是多少。编号为47的Chair进行完收尾工作后，标记会设为true，最终结束Chair对象的创建过程。（关于这个例子的更具体的分析和说明请参看《Java编程思想》的第四章）

　　关于垃圾收集的几点补充

　　经过上述的说明，可以发现垃圾回收有以下的几个特点：

　　（1）垃圾收集发生的不可预知性：由于实现了不同的垃圾收集算法和采用了不同的收集机制，所以它有可能是定时发生，有可能是当出现系统空闲CPU资源时发生，也有可能是和原始的垃圾收集一样，等到内存消耗出现极限时发生，这与垃圾收集器的选择和具体的设置都有关系。

　　（2）垃圾收集的精确性：主要包括2 个方面：（a）垃圾收集器能够精确标记活着的对象；（b）垃圾收集器能够精确地定位对象之间的引用关系。前者是完全地回收所有废弃对象的前提，否则就可能造成内存泄漏。而后者则是实现归并和复制等算法的必要条件。所有不可达对象都能够可靠地得到回收，所有对象都能够重新分配，允许对象的复制和对象内存的缩并，这样就有效地防止内存的支离破碎。（3）现在有许多种不同的垃圾收集器，每种有其算法且其表现各异，既有当垃圾收集开始时就停止应用程序的运行，又有当垃圾收集开始时也允许应用程序的线程运行，还有在同一时间垃圾收集多线程运行。

　　（4）垃圾收集的实现和具体的JVM 以及JVM的内存模型有非常紧密的关系。不同的JVM 可能采用不同的垃圾收集，而JVM 的内存模型决定着该JVM可以采用哪些类型垃圾收集。现在，HotSpot 系列JVM中的内存系统都采用先进的面向对象的框架设计，这使得该系列JVM都可以采用最先进的垃圾收集。

　　（5）随着技术的发展，现代垃圾收集技术提供许多可选的垃圾收集器，而且在配置每种收集器的时候又可以设置不同的参数，这就使得根据不同的应用环境获得最优的应用性能成为可能。

　　针对以上特点，我们在使用的时候要注意：

　　（1）不要试图去假定垃圾收集发生的时间，这一切都是未知的。比如，方法中的一个临时对象在方法调用完毕后就变成了无用对象，这个时候它的内存就可以被释放。

　　（2）Java中提供了一些和垃圾收集打交道的类，而且提供了一种强行执行垃圾收集的方法--调用System.gc()，但这同样是个不确定的方法。Java 中并不保证每次调用该方法就一定能够启动垃圾收集，它只不过会向JVM发出这样一个申请，到底是否真正执行垃圾收集，一切都是个未知数。

　　（3）挑选适合自己的垃圾收集器。一般来说，如果系统没有特殊和苛刻的性能要求，可以采用JVM的缺省选项。否则可以考虑使用有针对性的垃圾收集器，比如增量收集器就比较适合实时性要求较高的系统之中。系统具有较高的配置，有比较多的闲置资源，可以考虑使用并行标记/清除收集器。

　　（4）关键的也是难把握的问题是内存泄漏。良好的编程习惯和严谨的编程态度永远是最重要的，不要让自己的一个小错误导致内存出现大漏洞。

　　（5）尽早释放无用对象的引用。大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域(scope)后，自动设置为null，暗示垃圾收集器来收集该对象，还必须注意该引用的对象是否被监听，如果有，则要去掉监听器，然后再赋空值。

　　结束语

　　一般来说，Java开发人员可以不重视JVM中堆内存的分配和垃圾处理收集，但是，充分理解Java的这一特性可以让我们更有效地利用资源。同时要注意finalize()方法是Java的缺省机制，有时为确保对象资源的明确释放，可以编写自己的finalize方法。