String tempstr = "abcdefghijklmnopqrstuvwxyz";
int times = 5000;
long lstart1 = System.currentTimeMillis();
String str = "";
for (int i = 0; i < times; i ) {
str = tempstr;
}
long lend1 = System.currentTimeMillis();
long time = (lend1 - lstart1);
System.out.println(time);
可惜我的计算机不是超级计算机，得到的结果每次不一定一样一般为 46687左右。
也就是46秒。
我们再看看以下代码
String tempstr = "abcdefghijklmnopqrstuvwxyz";
int times = 5000;
long lstart2 = System.currentTimeMillis();
StringBuffer sb = new StringBuffer();
for (int i = 0; i < times; i ) {
sb.append(tempstr);
}
long lend2 = System.currentTimeMillis();
long time2 = (lend2 - lstart2);
System.out.println(time2);
得到的结果为 16 有时还是 0
所以结论很明显，StringBuffer 的速度几乎是String上万倍。当然这个数据不是很准确。因为循环的次数在100000次的时候，差异更大。不信你试试。
在大部分情况下 StringBuffer> String
StringBuffer
Java.lang.StringBuffer线程安全的可变字符序列。一个类似于String的字符串缓冲区，但不能修改。虽然在任意时间点上它都包含某种特定的字符序列，但通过某些方法调用可以改变该序列的长度和内容。
可将字符串缓冲区安全地用于多个线程。可以在必要时对这些方法进行同步，因此任意特定实例上的所有操作就好像是以串行顺序发生的，该顺序与所涉及的每个线程进行的方法调用顺序一致。
StringBuffer 上的主要操作是 append 和 insert方法，可重载这些方法，以接受任意类型的数据。每个方法都能有效地将给定的数据转换成字符串，然后将该字符串的字符追加或插入到字符串缓冲区中。append 方法始终将这些字符添加到缓冲区的末端；而 insert 方法则在指定的点添加字符。
例如，如果 z 引用一个当前内容是“start”的字符串缓冲区对象，则此方法调用 z.append("le")会使字符串缓冲区包含“startle”，而 z.insert(4, "le")将更改字符串缓冲区，使之包含“starlet”。
在大部分情况下 StringBuilder> StringBuffer
java.lang.StringBuilder
java.lang.StringBuilder一个可变的字符序列是5.0新增的。此类提供一个与 StringBuffer 兼容的 API，但不保证同步。该类被设计用作StringBuffer的一个简易替换，用在字符串缓冲区被单个线程使用的时候（这种情况很普遍）。如果可能，建议优先采用该类，因为在大多数实现中，它比StringBuffer 要快。两者的方法基本相同。
通过非官方试验测试，StringBuilder和StringBuffer的测试总结如下：
1． 为了获得更好的性能，在构造StringBuffer 或 StirngBuilder 时应尽可能指定它的容量。当然，如果你操作的字符串长度不超过16 个字符就不用了。
2． 相同情况下使用 StringBuilder 相比使用 StringBuffer 仅能获得 10%~15% 左右的性能提升，但却要冒多线程不安全的风险。而在现实的模块化编程中，负责某一模块的程序员不一定能清晰地判断该模块是否会放入多线程的环境中运行，因此：除非你能确定你的系统的瓶颈是在StringBuffer 上，并且确定你的模块不会运行在多线程模式下，否则还是用StringBuffer 吧 J
3． 用好现有的类比引入新的类更重要。很多程序员在使用StringBuffer 时是不指定其容量的（至少我见到的情况是这样），如果这样的习惯带入StringBuilder 的使用中，你将只能获得10 ％左右的性能提升（不要忘了，你可要冒多线程的风险噢）；但如果你使用指定容量的StringBuffer ，你将马上获得 45% 左右的性能提升，甚至比不使用指定容量的StirngBuilder 都快 30% 左右。
END：字符串操作的时候应该使用指定容量的StringBuffer!
