1700442518
1700442519
原因是Java为了避免在一个系统中大量产生String对象（为什么会大量产生？因为String字符串是程序中最经常使用的类型），于是就设计了一个字符串池（也有叫做字符串常量池，String Pool或String Constant Pool或String Literal Pool），在字符串池中所容纳的都是String字符串对象，它的创建机制是这样的：创建一个字符串时，首先检查池中是否有字面值相等的字符串，如果有，则不再创建，直接返回池中该对象的引用，若没有则创建之，然后放到池中，并返回新建对象的引用，这个池和我们平常所说的池概念非常相似。对于此例子来说，就是在创建第一个“中国”字符串时，先检查字符串池中有没有该对象，发现没有，于是就创建了“中国”这个字符串并放到池中，待再创建str2字符串时，由于池中已经有了该字符串，于是就直接返回了该对象的引用，此时，str1和str2指向的是同一个地址，所以使用“==”来判断那当然是相等的了。
1700442520
1700442521
那为什么使用new String（“中国”）就不相等了呢？因为直接声明一个String对象是不检查字符串池的，也不会把对象放到池中，那当然“==”为false了。
1700442522
1700442523
那为什么使用intern方法处理后就又相等了呢？因为intern会检查当前的对象在对象池中是否有字面值相同的引用对象，如果有则返回池中对象，如果没有则放置到对象池中，并返回当前对象。
1700442524
1700442525
可能有读者要问了，对象放到池中会不会产生线程安全问题呀？好问题，不过Java已经考虑到了，String类是一个不可变（Immutable）对象其实有两层意思：一是String类是final类，不可继承，不可能产生一个String的子类；二是在String类提供的所有方法中，如果有String返回值，就会新建一个String对象，不对原对象进行修改，这也就保证了原对象是不可改变的。
1700442526
1700442527
还有读者问了，放到池中，是不是要考虑垃圾回收问题呀？不用考虑了，虽然Java的每个对象都保存在堆内存中，但是字符串池非常特殊，它在编译期已经决定了其存在JVM的常量池（Constant Pool），垃圾回收器是不会对它进行回收的。
1700442528
1700442529
通过上面的介绍，我们发现Java在字符串的创建方面确实提供了非常好的机制，利用对象池不仅可以提高效率，同时也减少了内存空间的占用，建议大家在开发中使用直接量赋值方式，除非确有必要才新建立一个String对象。
1700442530
1700442531
1700442532
1700442533
1700442535
编写高质量代码：改善Java程序的151个建议 建议53：注意方法中传递的参数要求
1700442536
1700442537
有这样一个简单需求：写一个方法，实现从原始字符串中删除与之匹配的所有子字符串，比如在“蓝蓝的天，白云飘”中，删除“白云飘”，输出“蓝蓝的天，”，代码如下：
1700442538
1700442539
public class StringUtils{
1700442540
1700442541
//删除字符串
1700442542
1700442543
public static String remove（String source, String sub）{
1700442544
1700442545
return source.replaceAll（sub，””）；
1700442546
1700442547
}
1700442548
1700442549
}
1700442550
1700442551
StringUtils工具类很简单，它采用了String的replace方法，该方法是做字符串替换的，我们来编写一个测试用例，检查remove方法是否正确，如下所示：
1700442552
1700442553
assertTrue（StringUtils.remove（“好是好”，“好”）.equals（“是”））；
1700442554
1700442555
测试的结果是绿条（Green Bar），正确无误，但是再看看如下的测试用例：
1700442556
1700442557
assertTrue（StringUtils.remove（”$是$”，”$”）.equals（“是”））；
1700442558
1700442559
上面只是把“好是好”中的两个“好”字替换成了一个“$”符号，猜猜结果会是什么，应该也是绿条吧？但是非常遗憾，结果是红条，测试未通过。就这么简单一个的替换，为什么测试通不过呢？
1700442560
1700442561
问题就出在了replaceAll方法上，该方法确实需要传递两个String类型的参数，也确实进行了字符串替换，但是它要求第一个参数是一个正则表达式，符合正则表达式的字符串才会被替换。对上面的例子来说，第一个测试案例传递进来的是一个字符串“好”，这是一个全匹配查找替换，处理得非常正确，第二个测试案例传递进来的是“$”符号，“$”符号在正则表达式中表示的是字符串的结束位置，也就是说执行完repalceAll后，在字符串结尾的地方加上了空字符串，其结果还是“$是$”，所以测试失败也就在所难免了。问题清楚了，解决方案也就出来了：使用replace方法替代即可，它是repalceAll方法的简化版，可传递两个String参数继续替换，与我们的编码意图是相吻合的。
1700442562
1700442563
读者如果注意看JDK文档，会发现replace（CharSequence target, CharSequence replacement）方法是在1.5版本以后才开始提供的，在此之前如果要对一个字符串进行全替换，只能使用replaceAll方法，不过由于replaceAll方法的第二个参数使用了正则表达式，而且参数类型只要是CharSequence就可以（String的父类），所以很容易让使用者误解，稍有不慎就会导致严重的替换错误。
1700442564
1700442565
注意 replaceAll传递的第一个参数是正则表达式。
1700442566
1700442567
[
上一页 ]
[ :1.700442518e+09 ]
[
下一页 ]