什么是直接量?直接量是指:在程序中,通过源代码直接指定的值。eg:int personId = 8080 ;String name = "fancy" ; 对于 java 中的字符串直接量,JVM 会使用一个字符串驻留池来缓存它们。一般情况下,字符串驻留池中的字符串对象不会被 GC (Garbage Collection,垃圾回收) 所回收,当再次使用字符串驻留池中已有的字符串对象时候,无需再次创建它,而直接使它的引用变量指向字符串驻留池中已有的字符串对象。 String 基础: String 类代表字符串。字符串是常量,它们的值在创建之后是不能再被更改的。在 java 中除了 synchronized之外,不可变的类也是线程安全的,因此,String 类本身也是线程安全的。String 类的实例对象其实是可以被共享的。示例代码: 12 String name = "fancy"; // @13 String nick = "fancydeepin"; // @24 name = nick;5 System.out.println(name); // export:fancydeepin6 结果输出 :fancydeepin这是怎么回事?不是说 String 是不可变的字符串吗?怎么这里又变了?是这样的,在这里 name 只是一个引用类型变量,并不是一个 String 对象,@1中创建了一个 "fancy" 的字符串对象,@2中创建了一个 "fancydeepin" 的字符串对象,name 引用 (就像一个指针) 刚开始是指向 "fancy" 对象,而后,name 又重新指向 "fancydeepin" 对象,在示例代码中,整个过程只创建了两个 String 对象 (不知道我这样说你能不能理解,为什么是只创建了两个 String 对象?而不是 1个、3个... @3),一个是 "fancy" 对象,另外一个是 "fancydeepin" 对象。而这两个对象被创建出来后并没有被改变过,之所以程序会输出 fancydeepin,完全只是因为name 引用所指向的对象发生了改变。如果你是本着认真的态度看着我的贴子,细心的你,是否会留意到:当 name 引用重新指向另外一个对象的时候,那 name 之前引用的对象 ( "fancy" 对象 ) JVM 在底层会怎么处理它呢?是会立即来回收它来释放系统资源吗?答案是否定的。虽然这时候程序再也不访问 "fancy" 这个对象,但 JVM 还是不会来回收它,它将在程序运行期间久驻内存,为什么会这样呢?再往下说就扯到 java 的内存管理机制了,这里点到即止。在这里你可以简单的将它理解成 "fancy" 对象被缓存了起来 ( 实际上也是因为被缓存了 )。字符串驻留池当比较两个 String 对象时候,是应该用 "==" 呢?还是应该选择 equals 呢?相信绝大部分人绝大多时候使用的都是选择用 equals 方法。"==" 和 equals 的用法相信大家都很熟悉了,"==" 比较的是两个对象的哈希码值是否相等,而 equals 比较的是对象的内容是否一样。而绝大部分时候我们比较两个 String 对象的时候只是想比较它们的内容是否相等,这样看来,只能选 equals 了,但真的是这样吗?答案是否定的。你一样也可以用 "==" 来完成这样的一件事情,而且 "==" 的效率无论如何都是要比使用 equals 的效率要高的,但前提是,需要使用字符串的驻留池,才能使用 "==" 来替代 equals 作比较。String 里面有个方法叫 intern(),执行效率很高,但也许你还不曾用过,下面是摘自API中 intern() 方法的描述:“当调用 intern 方法时,如果池已经包含一个等于此 String 对象的字符串(用 equals(Object) 方法确定),则返回池中的字符串。否则,将此 String 对象添加到池中,并返回此 String 对象的引用。 它遵循以下规则:对于任意两个字符串 s 和 t,当且仅当 s.equals(t) 为 true 时,s.intern() == t.intern() 才为 true。 ”示例代码: 1 2 String name = new String("fancy"); 3 4 if(name == "fancy") { // false 5 System.out.println("equals 1"); 6 }else { 7 System.out.println("not equals 1"); // Be printed 8 } 9 10 name = name.intern(); // 将字符串添加到驻留池11 12 if(name == "fancy") { // true13 System.out.println("equals 2"); // Be printed14 }else {15 System.out.println("not equals 2");16 }17 输出结果: 12not equals 13equals 24 由上面的示例代码可以看到,字符串驻留池的使用是非常简单的,池中的对象可以被共享,只要你将字符串添加到池中,就能够直接使用"==" 来比较两个对象,而不是只能使用 equals 来作比较。将字符串添加到驻留池来使用 "==" 作比较的方式要比直接使用 equals 效率要高些。再论 String、StringBuffer 和 StringBuilder 由 synchronized 修饰的方法可以保证方法的线程安全,但是会降低该方法的执行效率; 翻开 API,很容易就能知道:StringBuffer 是线程安全的可变字符序列,StringBuilder 是一个可变的字符序列,是线程不安全的;网上说的所谓的使用 StringBuffer 的效率更高更好,这已经不合时宜,这是 java 1.5 之前的版本的说法,早过时了现在!!现在是反过来了,由于 StringBuilder 不是线程安全的,StringBuilder 效率会比 StringBuffer 效率更高一些。你可以不相信我说的,但你总该相信程序跑出来的结果吧,下面是示例代码: 1 2 StringBuffer buffer = new StringBuffer(); 3 StringBuilder builder = new StringBuilder(); 4 int COUNT = 10; // 测试 COUNT 趟 5 final int N = 100000; // 每趟操作 N 次 6 double beginTime, costTime; // 每趟开始时间和耗费时间 7 double bufferTotalTime = 0.0D, buliderTotalTime = 0.0D; // StringBuffer 和 StringBuilder 测试 COUNT 趟的总耗时 8 while(COUNT -- > -1) { 9 // 也可以测试每趟都创建一个新的对象,这样 StringBuilder 效率比 StringBuffer 的效率变得更明显了10 /**11 StringBuffer buffer = new StringBuffer();12 StringBuilder builder = new StringBuilder();13 */14 System.out.println("----------------------------------<" + (COUNT + 1) + ">");15 beginTime = System.currentTimeMillis();16 for(int i = 0; i < N; i++) {17 buffer.append(i);18 buffer.length();19 }20 costTime = System.currentTimeMillis() - beginTime;21 bufferTotalTime += costTime;22 System.out.println("StringBuffer 费时: --->> " + costTime);23 beginTime = System.currentTimeMillis();24 for(int i = 0; i < N; i++) {25 builder.append(i);26 builder.length();27 }28 costTime = System.currentTimeMillis() - beginTime;29 buliderTotalTime += costTime;30 System.out.println("StringBuilder 费时: --->> " + costTime);31 System.out.println("----------------------------------<" + (COUNT + 1) + ">");32 }33 System.out.println("bufferTotalTime / buliderTotalTime = " + (bufferTotalTime / buliderTotalTime));34 后台输出结果: 1 2----------------------------------<10> 3StringBuffer 费时: --->> 32.0 4StringBuilder 费时: --->> 16.0 5----------------------------------<10> 6----------------------------------<9> 7StringBuffer 费时: --->> 21.0 8StringBuilder 费时: --->> 15.0 9----------------------------------<9>10----------------------------------<8>11StringBuffer 费时: --->> 25.012StringBuilder 费时: --->> 35.013----------------------------------<8>14----------------------------------<7>15StringBuffer 费时: --->> 24.016StringBuilder 费时: --->> 8.017----------------------------------<7>18----------------------------------<6>19StringBuffer 费时: --->> 48.020StringBuilder 费时: --->> 38.021----------------------------------<6>22----------------------------------<5>23StringBuffer 费时: --->> 22.024StringBuilder 费时: --->> 8.025----------------------------------<5>26----------------------------------<4>27StringBuffer 费时: --->> 23.028StringBuilder 费时: --->> 9.029----------------------------------<4>30----------------------------------<3>31StringBuffer 费时: --->> 25.032StringBuilder 费时: --->> 7.033----------------------------------<3>34----------------------------------<2>35StringBuffer 费时: --->> 23.036StringBuilder 费时: --->> 7.037----------------------------------<2>38----------------------------------<1>39StringBuffer 费时: --->> 78.040StringBuilder 费时: --->> 59.041----------------------------------<1>42----------------------------------<0>43StringBuffer 费时: --->> 21.044StringBuilder 费时: --->> 11.045----------------------------------<0>46bufferTotalTime / buliderTotalTime = 1.605633802816901547 StringBuffer 在测试中平均耗时是 StringBuilder 的 1.6 倍以上,再测多次,都是 1.6 倍以上。StringBuffer 和 StringBuilder 的性能孰更加优,一眼明了。最后,如果你想知道 @3 (在上面我已经用红色粗体标出) 的结果,不妨说一下:eg:String mail = "fancydeepin" + "@" + "yeah.net";来,一起来看一下上面的这条语句,想一下,这条语句将会创建几个 String 的对象呢?1个? 2个? 3个? 4个? 5个? ... ...也许你会认为是4个,它们分别是:"fancydeepin"、"@"、"yeah.net"、"fancydeepin@yeah.net"也许你会认为是5个,它们分别是:"fancydeepin"、"@"、"yeah.net"、"fancydeepin@"、"fancydeepin@yeah.net"也许 ... ...但实际上,这条语句只创建了一个 String 对象!为什么会这样呢?原因很简单,这是因为,mail 在 编译的时候其值就已经确定,它就是 "fancydeepin@yeah.net" 。当程序处于运行期间且当上面的这条语句被执行到的时候,那么 mail 所引用的对象就会被创建,而 mail 的值由于在编译的时候已经确定它是 "fancydeepin@yeah.net" ,所以最终只有一个 String 对象被创建出来,而这个对象就是 "fancydeepin@yeah.net" 对象。这样解释都能够理解了吧?真的理解了吗?是真的理解才好,不妨再来看一个:eg:String mail = new String("fancydeepin@yeah.net");这回又创建了几个对象呢?答案是2个。为什么不是1个了呢?2个又是哪2个呢?可以很肯定的告诉你,它们分别是: "fancydeepin@yeah.net"、new String()这是因为,这回 mail 在编译的时候它的值是还不能够确定的,编译只是将源代码翻译成字节码,程序还并没有跑起来,还 new 不了对象,所以在编译完成之后,mail 的值是还不能够确定的。当程序处于运行期间且当上面的这条语句被执行到的时候,这时候才开始去确定 mail 的引用对象,首先,"fancydeepin@yeah.net" 对象会被创建,之后,再执行 new String(),所以这条语句最后实际上是创建了 2个 String 对象。
String 类代表字符串。字符串是常量,它们的值在创建之后是不能再被更改的。在 java 中除了 synchronized之外,不可变的类也是线程安全的,因此,String 类本身也是线程安全的。String 类的实例对象其实是可以被共享的。示例代码:
String
结果输出 :fancydeepin这是怎么回事?不是说 String 是不可变的字符串吗?怎么这里又变了?是这样的,在这里 name 只是一个引用类型变量,并不是一个 String 对象,@1中创建了一个 "fancy" 的字符串对象,@2中创建了一个 "fancydeepin" 的字符串对象,name 引用 (就像一个指针) 刚开始是指向 "fancy" 对象,而后,name 又重新指向 "fancydeepin" 对象,在示例代码中,整个过程只创建了两个 String 对象 (不知道我这样说你能不能理解,为什么是只创建了两个 String 对象?而不是 1个、3个... @3),一个是 "fancy" 对象,另外一个是 "fancydeepin" 对象。而这两个对象被创建出来后并没有被改变过,之所以程序会输出 fancydeepin,完全只是因为name 引用所指向的对象发生了改变。如果你是本着认真的态度看着我的贴子,细心的你,是否会留意到:当 name 引用重新指向另外一个对象的时候,那 name 之前引用的对象 ( "fancy" 对象 ) JVM 在底层会怎么处理它呢?是会立即来回收它来释放系统资源吗?答案是否定的。虽然这时候程序再也不访问 "fancy" 这个对象,但 JVM 还是不会来回收它,它将在程序运行期间久驻内存,为什么会这样呢?再往下说就扯到 java 的内存管理机制了,这里点到即止。在这里你可以简单的将它理解成 "fancy" 对象被缓存了起来 ( 实际上也是因为被缓存了 )。字符串驻留池当比较两个 String 对象时候,是应该用 "==" 呢?还是应该选择 equals 呢?相信绝大部分人绝大多时候使用的都是选择用 equals 方法。"==" 和 equals 的用法相信大家都很熟悉了,"==" 比较的是两个对象的哈希码值是否相等,而 equals 比较的是对象的内容是否一样。而绝大部分时候我们比较两个 String 对象的时候只是想比较它们的内容是否相等,这样看来,只能选 equals 了,但真的是这样吗?答案是否定的。你一样也可以用 "==" 来完成这样的一件事情,而且 "==" 的效率无论如何都是要比使用 equals 的效率要高的,但前提是,需要使用字符串的驻留池,才能使用 "==" 来替代 equals 作比较。String 里面有个方法叫 intern(),执行效率很高,但也许你还不曾用过,下面是摘自API中 intern() 方法的描述:“当调用 intern 方法时,如果池已经包含一个等于此 String 对象的字符串(用 equals(Object) 方法确定),则返回池中的字符串。否则,将此 String 对象添加到池中,并返回此 String 对象的引用。 它遵循以下规则:对于任意两个字符串 s 和 t,当且仅当 s.equals(t) 为 true 时,s.intern() == t.intern() 才为 true。 ”示例代码:
equals(Object)
s
t
s.equals(t)
true
s.intern() == t.intern()
tr
ue
输出结果:
由上面的示例代码可以看到,字符串驻留池的使用是非常简单的,池中的对象可以被共享,只要你将字符串添加到池中,就能够直接使用"==" 来比较两个对象,而不是只能使用 equals 来作比较。将字符串添加到驻留池来使用 "==" 作比较的方式要比直接使用 equals 效率要高些。再论 String、StringBuffer 和 StringBuilder
由 synchronized 修饰的方法可以保证方法的线程安全,但是会降低该方法的执行效率;
翻开 API,很容易就能知道:StringBuffer 是线程安全的可变字符序列,StringBuilder 是一个可变的字符序列,是线程不安全的;网上说的所谓的使用 StringBuffer 的效率更高更好,这已经不合时宜,这是 java 1.5 之前的版本的说法,早过时了现在!!现在是反过来了,由于 StringBuilder 不是线程安全的,StringBuilder 效率会比 StringBuffer 效率更高一些。你可以不相信我说的,但你总该相信程序跑出来的结果吧,下面是示例代码:
后台输出结果:
StringBuffer 在测试中平均耗时是 StringBuilder 的 1.6 倍以上,再测多次,都是 1.6 倍以上。StringBuffer 和 StringBuilder 的性能孰更加优,一眼明了。最后,如果你想知道 @3 (在上面我已经用红色粗体标出) 的结果,不妨说一下:eg:String mail = "fancydeepin" + "@" + "yeah.net";来,一起来看一下上面的这条语句,想一下,这条语句将会创建几个 String 的对象呢?1个? 2个? 3个? 4个? 5个? ... ...也许你会认为是4个,它们分别是:"fancydeepin"、"@"、"yeah.net"、"fancydeepin@yeah.net"也许你会认为是5个,它们分别是:"fancydeepin"、"@"、"yeah.net"、"fancydeepin@"、"fancydeepin@yeah.net"也许 ... ...但实际上,这条语句只创建了一个 String 对象!为什么会这样呢?原因很简单,这是因为,mail 在 编译的时候其值就已经确定,它就是 "fancydeepin@yeah.net" 。当程序处于运行期间且当上面的这条语句被执行到的时候,那么 mail 所引用的对象就会被创建,而 mail 的值由于在编译的时候已经确定它是 "fancydeepin@yeah.net" ,所以最终只有一个 String 对象被创建出来,而这个对象就是 "fancydeepin@yeah.net" 对象。这样解释都能够理解了吧?真的理解了吗?是真的理解才好,不妨再来看一个:eg:String mail = new String("fancydeepin@yeah.net");这回又创建了几个对象呢?答案是2个。为什么不是1个了呢?2个又是哪2个呢?可以很肯定的告诉你,它们分别是: "fancydeepin@yeah.net"、new String()这是因为,这回 mail 在编译的时候它的值是还不能够确定的,编译只是将源代码翻译成字节码,程序还并没有跑起来,还 new 不了对象,所以在编译完成之后,mail 的值是还不能够确定的。当程序处于运行期间且当上面的这条语句被执行到的时候,这时候才开始去确定 mail 的引用对象,首先,"fancydeepin@yeah.net" 对象会被创建,之后,再执行 new String(),所以这条语句最后实际上是创建了 2个 String 对象。
个人主页
beanutil
jutil
jexcel
orc