建议56：自由选择字符串拼接方法
对一个字符串拼接有三种方法：加号、concat方法及StringBuilder（或StringBuffer ,由于StringBuffer的方法与StringBuilder相同，不在赘述）的append方法，其中加号是最常用的，其它两种方式偶尔会出现在一些开源项目中，那这三者之间有什么区别吗？我们看看下面的例子：
1 public class Client56 {
2 public static void main(String[] args) {
3 // 加号拼接
4 String str = "";
5 long start1 = System.currentTimeMillis();
6 for (int i = 0; i < 100000; i++) {
7 str += "c";
8 }
9 long end1 = System.currentTimeMillis();
10 System.out.println("加号拼接耗时：" + (end1 - start1) + "ms");
11
12 // concat拼接
13 str = "";
14 long start2 = System.currentTimeMillis();
15 for (int i = 0; i < 100000; i++) {
16 str = str.concat("c");
17 }
18 long end2 = System.currentTimeMillis();
19 System.out.println("concat拼接耗时：" + (end2 - start2) + "ms");
20
21 // StringBuilder拼接
22 str = "";
23 StringBuilder buffer = new StringBuilder("");
24 long start3 = System.currentTimeMillis();
25 for (int i = 0; i < 100000; i++) {
26 buffer.append("c");
27 }
28 long end3 = System.currentTimeMillis();
29 System.out.println("StringBuilder拼接耗时：" + (end3 - start3) + "ms");
30
31 // StringBuffer拼接
32 str = "";
33 StringBuffer sb = new StringBuffer("");
34 long start4 = System.currentTimeMillis();
35 for (int i = 0; i < 100000; i++) {
36 sb.append("c");
37 }
38 long end4 = System.currentTimeMillis();
39 System.out.println("StringBuffer拼接耗时：" + (end4 - start4) + "ms");
40
41 }
42 }
上面是4种不同方式的字符串拼接方式，循环10万次后检查其执行时间，执行结果如下：
从上面的执行结果来看，在字符串拼接方式中,StringBuilder的append方法最快，StringBuffer的append方法次之（因为StringBuffer的append方法是线程安全的，同步方法自然慢一点），其次是concat方法，加号最慢，这是为何呢？
(1)、"+" 方法拼接字符串：虽然编辑器对字符串的加号做了优化，它会使用StringBuilder的append方法进行追加，按道理来说，其执行时间也应该是1ms，不过最终是通过toString方法转换为String字符串的，例子中的"+" 拼接的代码如下代码相同
str= new StringBuilder(str).append("c").toString();
注意看，它与纯粹使用StringBuilder的append方法是不同的：一是每次循环都会创建一个StringBuilder对象，二是每次执行完毕都要调用toString方法将其转换为字符串——它的执行时间就耗费在这里了！
(2)、concat方法拼接字符串：我们从源码上看一下concat方法的实现，代码如下：
public String concat(String str) {
int otherLen = str.length();
//如果追加字符长度为0，则返回字符串本身
if (otherLen == 0) {
return this;
}
int len = value.length;
char buf[] = Arrays.copyOf(value, len + otherLen);
str.getChars(buf, len);
//产生一个新的字符串
return new String(buf, true);
}
其整体看上去就是一个数组拷贝，虽然在内存中处理都是原子性操作，速度非常快，不过，注意看最后的return语句，每次concat操作都会创建一个String对象，这就是concat速度慢下来的真正原因，它创建了10万个String对象呀。
(3)、append方法拼接字符串：StringBuilder的append方法直接由父类AbstractStringBuilder实现，其代码如下：
public StringBuilder append(String str) {
super.append(str);
return this;
}
public AbstractStringBuilder append(String str) {
//如果是null值，则把null作为字符串处理
if (str == null) str = "null";
int len = str.length();
ensureCapacityInternal(count + len);
//字符串复制到目标数组
str.getChars(0, len, value, count);
count += len;
return this;
}
看到没，整个append方法都在做字符数组处理，加长，然后拷贝数组，这些都是基本的数据处理，没有创建任何对象，所以速度也就最快了！注意：例子中是在随后通过StringBuilder的toString方法返回了一个字符串，也就是说在10万次循环结束后才生成了一个String对象。StringBuffer的处理和此类似，只是方法是同步的而已。
四者的实现方法不同，性能也就不同，但并不表示我们一定要使用StringBuilder，这是因为"+"非常符合我们的编码习惯，适合阅读，两个字符串拼接，就用加号连一下，这很正常，也很友好，在大多数情况下我们都可以使用加号操作，只有在系统性能临界(如在性能 " 增长一分则太长" 的情况下)的时候才可以考虑使用concat或append方法。而且，很多时候系统80% 的性能是消耗在20%的代码上的，我们的精力应该更多的投入到算法和结构上。
注意：适当的场景使用适当的字符串拼接方式。
建议57：推荐在复杂字符串操作中使用正则表达式
字符串的操作，诸如追加、合并、替换、倒叙、分割等，都是在编码过程中经常用到的，而且Java也提供了append、replace、reverse、spit等方法来完成这些操作，它们使用起来确实方便，但是更多时候，需要使用正则表达式来完成复杂的处理，我们来看一个例子：统计一篇文章中英文单词的数量，很简单吧，代码如下：
1 public class Client57 {
2 public static void main(String[] args) {
3 Scanner input = new Scanner(System.in);
4 while (input.hasNext()) {
5 String str = input.nextLine();
6 // 使用split方法分割后统计
7 int wordsCount = str.split(" ").length;
8 System.out.println(str + "单词数：" + wordsCount);
9 }
10 }
11 }
使用spit方法根据空格来分割单词，然后计算分割后的数组长度，这种方法可靠吗？我们看看输出结果：
注意看输出，除了第一个输入"Today is Monday"正确外，其它的都是错误的！第二条输入中的单词"Monday"前有2个连续的空格，第三条输入中"No"单词前后都没有空格，最后一个输入则没有把连写符号" ' "考虑进去，这样统计出来的单词数量肯定是错误一堆，那怎么做才合理呢？
如果考虑使用一个循环来处理这样的"异常"情况，会使程序的稳定性变差，而且要考虑太多太多的因素，这让程序的复杂性也大大提高了。那如何处理呢？可以考虑使用正则表达式，代码如下：
1 public class Client57 {
2 public static void main(String[] args) {
3 Scanner input = new Scanner(System.in);
4 while (input.hasNext()) {
5 String str = input.nextLine();
6 //正则表达式对象
7 Pattern p = Pattern.compile("\\b\\w+\\b");
8 //生成匹配器
9 Matcher matcher =p.matcher(str);
10 int wordsCount = 0;
11 while(matcher.find()){
12 wordsCount++;
13 }
14 System.out.println(str + "单词数：" + wordsCount);
15 }
16 }
17 }
准不准确，我们看看相同的输入，输出结果如下：
每项的输出都是准确的，而且程序也不复杂，先生成一个正则表达式对象，然后使用匹配器进行匹配，之后通过一个while循环统计匹配的数量。需要说明的是，在Java的正则表达式中"\b" 表示的是一个单词的边界，它是一个位置界定符，一边为字符或数字，另外一边为非字符或数字，例如"A"这样一个输入就有两个边界，即单词"A"的左右位置，这也就说明了为什么要加上"\w"（它表示的是字符或数字）。
正则表达式在字符串的查找，替换，剪切，复制，删除等方面有着非凡的作用，特别是面对大量的文本字符需要处理（如需要读取大量的LOG日志）时，使用正则表达式可以大幅地提高开发效率和系统性能，但是正则表达式是一个恶魔，它会使程序难以读懂，想想看，写一个包含^、$、\A、\s、\Q、+、？、()、{}、[]等符号的正则表达式，然后再告诉你这是一个" 这样，这样......"字符串查找，你是不是要崩溃了？这个代码确实不好阅读，你就要在正则上多下点功夫了。
注意：正则表达式是恶魔，威力巨大，但难以控制。
建议58：强烈建议使用UTF编码
Java的乱码问题由来已久，有经验的开发人员肯定遇到过乱码，有时从Web接收的乱码，有时从数据库中读取的乱码，有时是在外部接口中接收的乱码文件，这些都让我们困惑不已，甚至是痛苦不堪，看如下代码：
1 public class Client58 {
2 public static void main(String[] args) throws UnsupportedEncodingException {
3 String str = "汉字";
4 // 读取字节
5 byte b[] = str.getBytes("UTF-8");
6 // 重新生成一个新的字符串
7 System.out.println(new String(b));
8 }
9 }
Java文件是通过IDE工具默认创建的，编码格式是GBK，大家想想看上面的输出结果会是什么？可能是乱码吧？两个编码格式不同。我们暂时不说结果，先解释一下Java中的编码规则。Java程序涉及的编码包括两部分：
(1)、Java文件编码：如果我们使用记事本创建一个.java后缀的文件，则文件的编码格式就是操作系统默认的格式。如果是使用IDE工具创建的，如Eclipse，则依赖于IDE的设置，Eclipse默认是操作系统编码（Windows一般为GBK）；
(2)、Class文件编码：通过javac命令生成的后缀名为.class的文件是UTF-8编码的UNICODE文件，这在任何操作系统上都是一样的，只要是.class文件就会使UNICODE格式。需要说明的是，UTF是UNICODE的存储和传输格式，它是为了解决UNICODE的高位占用冗余空间而产生的，使用UTF编码就意味着字符集使用的是UNICODE.
再回到我们的例子上，getBytes方法会根据指定的字符集取出字节数组(这里按照UNICODE格式来提取)，然后程序又通过new String(byte [] bytes)重新生成一个字符串，来看看String的这个构造函数：通过操作系统默认的字符集解码指定的byte数组，构造一个新的String，结果已经很清楚了，如果操作系统是UTF-8的话，输出就是正确的，如果不是，则会是乱码。由于这里使用的是默认编码GBK，那么输出的结果也就是乱码了。我们再详细分解一下运行步骤：
步骤1：创建Client58.java文件：该文件的默认编码格式GBK（如果是Eclipse，则可以在属性中查看到）。
步骤2：编写代码(如上)；
步骤3：保存，使用javac编译，注意我们没有使用"javac -encoding GBK Client58.java" 显示声明Java的编码方式，javac会自动按照操作系统的编码(GBK)读取Client58.java文件，然后将其编译成.class文件。
步骤4：生成.class文件。编译结束，生成.class文件，并保存到硬盘上，此时 .class文件使用的UTF-8格式编码的UNICODE字符集，可以通过javap 命令阅读class文件，其中" 汉字"变量也已经由GBK转变成UNICODE格式了。
步骤5：运行main方法，提取"汉字"的字节数组。"汉字" 原本是按照UTF-8格式保存的，要再提取出来当然没有任何问题了。
步骤6：重组字符串，读取操作系统默认的编码GBK，然后重新编码变量b的所有字节。问题就在这里产生了：因为UNICODE的存储格式是两个字节表示一个字符(注意：这里是指UCS-2标准)，虽然GBK也是两个字节表示一个字符，但两者之间没有映射关系，只要做转换只能读取映射表，不能实现自动转换----于是JVM就按照默认的编码方式(GBK)读取了UNICODE的两个字节。
步骤7：输出乱码，程序运行结束，问题清楚了，解决方案也随之产生，方案有两个。
步骤8：修改代码，明确指定编码即可，代码如下：
System.out.println(new String(b,"UTF-8"));
步骤9：修改操作系统的编码方式，各个操作系统的修改方式不同，不再赘述。
我们可以把字符串读取字节的过程看做是数据传输的需要(比如网络、存储)，而重组字符串则是业务逻辑的需求，这样就可以是乱码重现：通过JDBC读取的字节数组是GBK的，而业务逻辑编码时采用的是UTF-8，于是乱码就产生了。对于此类问题，最好的解决办法就是使用统一的编码格式，要么都用GBK，要么都用UTF-8，各个组件、接口、逻辑层、都用UTF-8，拒绝独树一帜的情况。
问题清楚了，我么看看以下代码：
1 public class Client58 {
2 public static void main(String[] args) throws UnsupportedEncodingException {
3 String str = "汉字";
4 // 读取字节
5 byte b[] = str.getBytes("GB2312");
6 // 重新生成一个新的字符串
7 System.out.println(new String(b));
8 }
9 }
仅仅修改了读取字节的编码方式(修改成了GB2312)，结果会怎样呢？又或者将其修改成GB18030，结果又是怎样的呢？结果都是"汉字"，不是乱码。这是因为GB2312是中文字符集的V1.0版本，GBK是V2.0版本，GB18030是V3.0版本，版本是向下兼容的，只是它们包含的汉字数量不同而已，注意UNICODE可不在这个序列之内。
注意：一个系统使用统一的编码。
建议59：对字符串持有一种宽容的心态
在Java 中一涉及中文处理就会冒出很多问题来，其中排序也是一个让人头疼的课题，我们看如下代码：
1 public class Client59 {
2 public static void main(String[] args) {
3 String[] strs = { "张三(Z)", "李四(L)", "王五(W)" };
4 Arrays.sort(strs);
5 int i = 0;
6 for (String str : strs) {
7 System.out.println((++i) + "、" + str);
8 }
9 }
10 }
上面的代码定义了一个数组，然后进行升序排序，我们期望的结果是按照拼音升序排列，即为李四、王五、张三，但是结果却不是这样的：
这是按照什么排的序呀，非常混乱!我们知道Arrays工具类的默认排序是通过数组元素的compareTo方法进行比较的，那我们来看String类的compareTo的主要实现：
1 public int compareTo(String anotherString) {
2 int len1 = value.length;
3 int len2 = anotherString.value.length;
4 int lim = Math.min(len1, len2);
5 char v1[] = value;
6 char v2[] = anotherString.value;
7
8 int k = 0;
9 while (k < lim) {
10 char c1 = v1[k];
11 char c2 = v2[k];
12 if (c1 != c2) {
13 return c1 - c2;
14 }
15 k++;
16 }
17 return len1 - len2;
18 }
上面的代码先取得字符串的字符数组，然后一个一个地比较大小，注意这里是字符比较(减号操作符)，也就是UNICODE码值比较，查一下UNICODE代码表，"张" 的码值是5F20，"李"是674E,这样一看，"张" 排在 "李" 前面也就很正确了---但这明显与我们的意图冲突了。这一点在JDK的文档中也有说明：对于非英文的String排序可能会出现不准确的情况，那该如何解决这个问题呢？Java推荐使用collator类进行排序，那好，我们把代码修改一下：
public class Client59 {
public static void main(String[] args) {
String[] strs = { "张三(Z)", "李四(L)", "王五(W)" };
//定义一个中文排序器
Comparator c = Collator.getInstance(Locale.CHINA);
Arrays.sort(strs,c);
int i = 0;
for (String str : strs) {
System.out.println((++i) + "、" + str);
}
}
}
输出结果：
1、李四(L)
2、王五(W)
3、张三(Z)
这确实是我们期望的结果，应该不会错了吧！但是且慢，中国的汉字博大精深，Java是否都能精确的排序呢？最主要的一点是汉字中有象形文字，音形分离，是不是每个汉字都能按照拼音的顺序排好呢？我们写一个复杂的汉字来看看：
1 public class Client59 {
2 public static void main(String[] args) {
3 String[] strs = { "犇(B)", "鑫(X)", "淼(M)" };
4 //定义一个中文排序器
5 Comparator c = Collator.getInstance(Locale.CHINA);
6 Arrays.sort(strs,c);
7 int i = 0;
8 for (String str : strs) {
9 System.out.println((++i) + "、" + str);
10 }
11 }
12 }
输出结果如下：
输出结果又乱了，不要责怪Java，它们已尽量为我们考虑了，只是因为我们的汉字文化太博大精深了，要做好这个排序确实有点为难它，更深层次的原因是Java使用的是UNICODE编码，而中文UNICODE字符集来源于GB18030的,GB18030又是从GB2312发展起来，GB2312是一个包含了7000多个字符的字符集，它是按照拼音排序，并且是连续的，之后的GBK、GB18030都是在其基础上扩充而来的，所以要让它们完整的排序也就难上加难了。
如果排序对象是经常使用的汉字，使用Collator类排序完全可以满足我们的要求，毕竟GB2312已经包含了大部分的汉字，如果需要严格排序，则要使用一些开源项目来自己实现了，比如pinyin4j可以把汉字转换为拼音，然后我们自己来实现排序算法，不过此时你会发现要考虑的诸如算法、同音字、多音字等众多问题。
注意：如果排序不是一个关键算法，使用Collator类即可。
