前言
"我的风格比较偏传统和经典" 小明说,"我们在打扮自己的问题上还是蛮冒险的...我觉得当你是只狗的时候,穿什么都hold的住!"
哈哈哈,脱离单身狗快两年了,生活中除了爱情,不变的还有对代码的挚爱,总之始于热爱,忠于爱情,陷于代码。
前半年规划人生,后半年开始规划,最近发生的一些事情还是让自己倍感压力的,生活可以知足常乐,但人生不可以,如果你不把生命体验到极致,也许会被未来的自己所鄙视。
前世今生
String不可变这个话题应该是老生长谈了,你可以说它就是设计者的龟腚,然后巴拉巴拉说出一大堆优点,也可以说它忠于爱情,只要JVM存活,它便万年不变。
String自打娘胎一出生就跟他们的兄弟姐妹不一样,好好的娃被戴了一个final的帽子,以至于byte,int,short,long等基本类型的小伙们都不带它玩。
但是,String并不是一个简单的人设,如果各位小伙伴们仔细查阅其源码,那可是浩浩荡荡的3000+行代码了,如果你一个controller能这样的代码量也是非常不错的。
如果你仔细阅读源码注释,你会发现这样一句话:
Strings are constant; their values cannot be changed after they are created
大致意思就是String是个常量,从一出生就注定不可变。
我觉得到这里各位小伙们应该就知道为什么String不可变了,戴了个final的帽子,官方注释说明创建后不能被改变,但是为什么String要使用final修饰呢?
面试精选
在了解String不可变之前,我觉得有必要分析一道经典的面试题:
public class Apple {public static void main(String[] args) {
String a = "abc";
String b = "abc";
String c = new String("abc");
System.out.println(a==b);
System.out.println(a.equals(b));
System.out.println(a==c);
System.out.println(a.equals(c));
}
}
答案是:true、true、false、true
如图所示,代码中的abc对应个的abc:
我觉得有必要把a、b、c替换成小明、红、光,abc替换成红苹果重新梳理一下流程:
小明想吃红苹果,小明的爸爸首先会在树上寻找是否有红苹果,有的话,爸爸就说,这个苹果归你了,如果没有,假设万能的小明爸爸也可以给他造一个。
这时候小红过来了,爸爸我也想吃那个红苹果,并且强烈要求要拿一个,就这样小明和小红共享了这个苹果。
小光是个听话的孩子,只要是红苹果就行,我可不想跟他俩争什么,爸爸就这样从超市里给小光买了一个红苹果。
小明和小红的是同一个苹果,这个是不变的事实,无论你怎么比较。
小红,小明和小光的都是红苹果,但却不是同一个苹果。
你可以把苹果树理解成常量池,爸爸购买苹果的过程理解为new对象,当然,举例可能不是太恰当,只是为了大家更好的理解。
回到代码本来来说,因为String太过常用,JAVA类库的设计者在实现时做了个小小的变化,即采用了享元模式,每当生成一个新内容的字符串时,他们都被添加到一个共享池中,当第二次再次生成同样内容的字符串实例时,就共享此对象,而不是创建一个新对象,但是这样的做法仅仅适合于通过=符号进行的初始化。
需要说明一点的是,在object中,equals()是用来比较内存地址的,但是String重写了equals()方法,用来比较内容的,即使是不同地址,只要内容一致,也会返回true,这也就是为什么a.equals(c)返回true的原因了。
不可变的好处
首先,我们应该站在设计者的角度思考问题,而不是觉得这不好,那不合理:
可以实现多个变量引用堆内存中的同一个字符串实例,避免创建的开销。
我们的程序中大量使用了String字符串,有可能是出于安全性考虑。
大家都知道HashMap中key为String类型,如果可变将变的多么可怕。
当我们在传参的时候,使用不可变类不需要去考虑谁可能会修改其内部的值,如果使用可变类的话,可能需要每次记得重新拷贝出里面的值,性能会有一定的损失。
其次,我们再分析有没有更好的解决方案:
然,对于我来说,并没有!!!
然,对于我来说,并没有!!!
然,对于我来说,并没有!!!
总结
了解到String是不可变的,知道了常量池是怎么个东西。
重温了面试题,有兴趣的小伙伴也可以去阅读下String的源码,浩浩荡荡的3000+。
String 被new时是要创建对象的,+ 号拼接同理,程序中尽量不要使用 + 拼接,推荐使用StringBuffer或者StringBuilder。