about String

轻帆向南 — Wed, 22 Feb 2012 09:26:00 GMT

【zz 网上关于String的讨论很多，这段讲解让我稍稍有了点头绪：）】
先来了解一下JVM运行时数据区的内存模型。
《深入Java虚拟机》书中是这样描述的：JVM运行时数据区的内存模型由五部分组成：
【1】方法区
【2】堆
【3】Java栈
【4】PC寄存器
【5】本地方法栈

对于String s = "hello" ,它的虚拟机指令：

Java code

 0:   ldc     #16; //string hello     2:   astore_1   3:   return

对于上面虚拟机指令，其各自的指令流程在《深入Java虚拟机》这样描述到(结合上面实例)：

ldc指令格式：ldc,index
ldc指令过程：
要执行ldc指令，jvm首先查找index所指定的常量池入口，在index指向的常量池入口，jvm将会查找constant_integer_info，constant_float_info和constant_string_info入口。如果还没有这些入口，jvm会解析它们。而对于上面的hahajvm会找到constant_string_info入口，同时，将把指向被拘留String对象（由解析该入口的进程产生）的引用压入操作数栈。

astore_1指令格式：astore_1
astore_1指令过程：
要执行astore_1指令，jvm从操作数栈顶部弹出一个引用类型或者returnaddress类型值，然后将该值存入由索引1指定的局部变量中,即将引用类型或者returnaddress类型值存入局部变量1。

return 指令的过程：
从方法中返回，返回值为void。

谈一下我个人理解：
从上面的ldc指令的执行过程可以得出：s的值是来自被拘留string对象（由解析该入口的进程产生）的引用，即可以理解为是从被拘留string对象的引用复制而来的，故我个人的理解是s的值是存在栈当中。上面是对于s值得分析，接着是对于"hello"值的分析,我们知道，对于string s = "hello" 其中"hello"值在java程序编译期就确定下来了的。简单一点说，就是haha的值在程序编译成class文件后，就在class文件中生成了（大家可以用ue编辑器或其它文本编辑工具在打开class文件后的字节码文件中看到这个hello值）。执行java程序的过程中，第一步是class文件生成，然后被jvm装载到内存执行。那么jvm装载这个class到内存中，其中的hello这个值，在内存中是怎么为其开辟空间并存储在哪个区域中呢？

说到这里，我们不妨先来了解一下jvm常量池这个结构，《深入Java虚拟机》书中有这样的描述：

常量池
虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用到常量的一个有序集和，包括直接常量（string,integer和floating point常量）和对其他类型，字段和方法的符号引用。对于string常量，它的值是在常量池中的。而jvm中的常量池在内存当中是以表的形式存在的，对于string类型，有一张固定长度的constant_string_info表用来存储文字字符串值，注意：该表只存储文字字符串值，不存储符号引用。说到这里，对常量池中的字符串值的存储位置应该有一个比较明了的理解了。

在介绍完jvm常量池的概念后，接着谈开始提到的"hello"的值的内存分布的位置。对于haha的值，实际上是在class文件被jvm装载到内存当中并被引擎在解析ldc指令并执行ldc指令之前，jvm就已经为haha这个字符串在常量池的constant_string_info表中分配了空间来存储hello这个值。既然hello这个字符串常量存储在常量池中，根据《深入java虚拟机》书中描述：常量池是属于类型信息的一部分，类型信息也就是每一个被转载的类型，这个类型反映到jvm内存模型中是对应存在于jvm内存模型的方法区中，也就是这个类型信息中的常量池概念是存在于在方法区中，而方法区是在jvm内存模型中的堆中由jvm来分配的。所以，hello的值是应该是存在堆空间中的。

而对于string s = new string("hello") ,它的jvm指令：

Java code

 0:   new     #16; //class string  3:   dup  4:   ldc     #18; //string hello  6:   invokespecial   #20; //method java/lang/string."":(ljava/lang/string;)v  9:   astore_1  10:  return

对于上面虚拟机指令，其各自的指令流程在《深入java虚拟机》这样描述到(结合上面实例)：

new指令格式：new indexbyte1,indexbyte2
new指令过程：
要执行new指令，jvm通过计算(indextype1<<8)|indextype2生成一个指向常量池的无符号16位索引。然后jvm根据计算出的索引查找常量池入口。该索引所指向的常量池入口必须为constant_class_info。如果该入口尚不存在，那么jvm将解析这个常量池入口，该入口类型必须是类。jvm从堆中为新对象映像分配足够大的空间，并将对象的实例变量设为默认值。最后jvm将指向新对象的引用objectref压入操作数栈。

dup指令格式：dup
dup指令过程：
要执行dup指令，jvm复制了操作数栈顶部一个字长的内容，然后再将复制内容压入栈。本指令能够从操作数栈顶部复制任何单位字长的值。但绝对不要使用它来复制操作数栈顶部任何两个字长(long型或double型)中的一个字长。上面例中，即复制引用objectref，这时在操作数栈存在2个引用。

ldc指令格式：ldc,index
ldc指令过程：
要执行ldc指令，jvm首先查找index所指定的常量池入口，在index指向的常量池入口，jvm将会查找constant_integer_info，constant_float_info和constant_string_info入口。如果还没有这些入口，jvm会解析它们。而对于上面的haha,jvm会找到constant_string_info入口，同时，将把指向被拘留string对象（由解析该入口的进程产生）的引用压入操作数栈。

invokespecial指令格式：invokespecial,indextype1,indextype2
invokespecial指令过程：对于该类而言，该指令是用来进行实例初始化方法的调用。鉴于该指令篇幅，具体可以查阅《深入java虚拟机》中描述。上面例子中，即通过其中一个引用调用string类的构造器，初始化对象实例，让另一个相同的引用指向这个被初始化的对象实例，然后前一个引用弹出操作数栈。

astore_1指令格式：astore_1
astore_1指令过程：
要执行astore_1指令，jvm从操作数栈顶部弹出一个引用类型或者returnaddress类型值，然后将该值存入由索引1指定的局部变量中,即将引用类型或者returnaddress类型值存入局部变量1。

return 指令的过程:
从方法中返回，返回值为void。

要执行astore_1指令，jvm从操作数栈顶部弹出一个引用类型或者returnaddress类型值，然后将该值存入由索引1指定的局部变量中,即将引用类型或者returnaddress类型值存入局部变量1。

通过上面6个指令，可以看出，string s = new string("hello");中的hello存储在堆空间中，而s则是在操作数栈中。
上面是对s和haha值的内存情况的分析和理解；那对于string s = new string("hello");语句,到底创建了几个对象呢?
我的理解：这里"hello"本身就是常量池中的一个对象，而在运行时执行new string()时，将常量池中的对象复制一份放到堆中，并且把堆中的这个对象的引用交给s持有。所以这条语句就创建了2个string对象。

下面是一些string相关的常见问题：
String中的final用法和理解
final stringbuffer a = new stringbuffer("111");
final stringbuffer b = new stringbuffer("222");
a=b;//此句编译不通过
final stringbuffer a = new stringbuffer("111");
a.append("222");//编译通过
可见，final只对引用的"值"(即内存地址)有效，它迫使引用只能指向初始指向的那个对象，改变它的指向会导致编译期错误。至于它所指向的对象的变化，final是不负责的。

String 常量池问题的几个例子
下面是几个常见例子的比较分析和理解：
【1】

Java code

 String a = "a1";   String b = "a" + 1;   System.out.println((a == b)); //result = true  String a = "atrue";   String b = "a" + "true";   System.out.println((a == b)); //result = true  String a = "a3.4";   String b = "a" + 3.4;   System.out.println((a == b)); //result = true

分析：jvm对于字符串常量的"+"号连接，将程序编译期，jvm就将常量字符串的"+"连接优化为连接后的值，拿"a" + 1来说，经编译器优化后在class中就已经是a1。在编译期其字符串常量的值就确定下来，故上面程序最终的结果都为true。

【2】

Java code

 String a = "ab";   String bb = "b";   String b = "a" + bb;   System.out.println((a == b)); //result = false

分析：jvm对于字符串引用，由于在字符串的"+"连接中，有字符串引用存在，而引用的值在程序编译期是无法确定的，即"a" + bb无法被编译器优化，只有在程序运行期来动态分配并将连接后的新地址赋给b。所以上面程序的结果也就为false。

【3】

Java code

 String a = "ab";   final String bb = "b";   String b = "a" + bb;   System.out.println((a == b)); //result = true

分析：和[3]中唯一不同的是bb字符串加了final修饰，对于final修饰的变量，它在编译时被解析为常量值的一个本地拷贝存储到自己的常量池中或嵌入到它的字节码流中。所以此时的"a" + bb和"a" + "b"效果是一样的。故上面程序的结果为true。

【4】

Java code

 String a = "ab";   final String bb = getbb();   String b = "a" + bb;   System.out.println((a == b)); //result = false   private static string getbb() {    return "b";   }

分析：jvm对于字符串引用bb，它的值在编译期无法确定，只有在程序运行期调用方法后，将方法的返回值和"a"来动态连接并分配地址为b，故上面程序的结果为false。

通过上面4个例子可以得出得知：
string s = "a" + "b" + "c";
就等价于string s = "abc";

string a = "a";
string b = "b";
string c = "c";
string s = a + b + c;
这个就不一样了，最终结果等于：
stringbuffer temp = new stringbuffer();
temp.append(a).append(b).append(c);
string s = temp.tostring();
由上面的分析结果，可就不难推断出string 采用连接运算符（+）效率低下原因分析，形如这样的代码：

Java code

 public class test {    public static void main (String args[]) {      String s = null;      for (int i = 0; i < 100; i++) {        s += "a";      }    }  }

每做一次 + 就产生个stringbuilder对象，然后append后就扔掉。下次循环再到达时重新产生个stringbuilder对象，然后 append 字符串，如此循环直至结束。如果我们直接采用 stringbuilder 对象进行 append 的话，我们可以节省 n - 1 次创建和销毁对象的时间。所以对于在循环中要进行字符串连接的应用，一般都是用stringbuffer或stringbulider对象来进行append操作。

string对象的intern方法理解和分析：

Java code

 public class test4 {    private static String a = "ab";     public static void main (String[] args){      String s1 = "a";      String s2 = "b";      String s = s1 + s2;      System.out.println(s == a);//false      System.out.println(s.intern() == a);//true      }  }

这里用到java里面是一个常量池的问题。对于s1+s2操作，其实是在堆里面重新创建了一个新的对象,s保存的是这个新对象在堆空间的的内容，所以s与a的值是不相等的。而当调用s.intern()方法，却可以返回s在常量池中的地址值，因为a的值存储在常量池中，故s.intern和a的值相等。

http://topic.csdn.net/u/20081231/13/4c342bec-5afd-4ab7-bce7-4b7b98cabbc2.html

轻帆向南 2012-02-22 17:26 发表评论

内存不足 java.lang.OutOfMemoryError: Java heap space

轻帆向南 — Thu, 23 Sep 2010 04:45:00 GMT

摘要: 阅读全文

轻帆向南 2010-09-23 12:45 发表评论

关于GridBagLayout网络上一篇很好的文章

轻帆向南 — Sat, 01 May 2010 14:26:00 GMT

摘要: 阅读全文

轻帆向南 2010-05-01 22:26 发表评论

关于有模式和无模式对话框

轻帆向南 — Wed, 07 Apr 2010 12:25:00 GMT

做GUI用到对话框，上网查了下解释，有篇文章是对着MFC来的，说的挺好，转过来~~

非模态对话框与模态对话框相比有下列不同之处：
非模态对话框的模板必须具有Visible风格，否则对话框将不可见，而模态对话框则无需
设置该项风格。更保险的办法是调用CWnd::ShowWindow(SW_SHOW)来显示对话框，而不管
对话框是否具有Visible风格。
非模态对话框对象是用new操作符在堆中动态创建的，而不是以成员变量的形式嵌入到别
的对象中或以局部变量的形式构建在堆栈上。通常应在对话框的拥有者窗口类内声明一
个指向对话框类的指针成员变量，通过该指针可访问对话框对象。
通过调用CDialog::Create函数来启动对话框，而不是CDialog::DoModal，这是模态对话
框的关键所在。由于Create函数不会启动新的消息循环，对话框与应用程序共用同一个
消息循环，这样对话框就不会垄断用户的输入。Create在显示了对话框后就立即返回，
而DoModal是在对话框被关闭后才返回的。众所周知，在MFC程序中，窗口对象的生存期
应长于对应的窗口，也就是说，不能在未关闭屏幕上窗口的情况下先把对应的窗口对象
删除掉。由于在Create返回后，不能确定对话框是否已关闭，这样也就无法确定对话框
对象的生存期，因此只好在堆中构建对话框对象，而不能以局部变量的形式来构建之。

必须调用CWnd::DestroyWindow而不是CDialog::EndDialog来关闭非模态对话框。调用C
Wnd::DestroyWindow是直接删除窗口的一般方法。由于缺省的CDialog::OnOK和CDialog
∶:OnCancel函数均调用EndDialog，故程序员必须编写自己的OnOK和OnCancel函数并且在
函数中调用DestroyWindow来关闭对话框。
因为是用new操作符构建非模态对话框对象，因此必须在对话框关闭后，用delete操作符
删除对话框对象。在屏幕上一个窗口被删除后，框架会调用CWnd::PostNcDestroy，这是
一个虚拟函数，程序可以在该函数中完成删除窗口对象的工作，具体代码如下
void CModelessDialog::PostNcDestroy
{
delete this; //删除对象本身
}
这样，在删除屏幕上的对话框后，对话框对象将被自动删除。拥有者对象就不必显式的
调用delete来删除对话框对象了。
必须有一个标志表明非模态对话框是否是打开的。这样做的原因是用户有可能在打开一
个模态对话框的情况下，又一次选择打开命令。程序根据标志来决定是打开一个新的对
话框，还是仅仅把原来打开的对话框激活。通常可以用拥有者窗口中的指向对话框对象
的指针作为这种标志，当对话框关闭时，给该指针赋NULL值，以表明对话框对象已不存
在了。

轻帆向南 2010-04-07 20:25 发表评论

（转）从File类开始java IO 系统介绍

轻帆向南 — Mon, 29 Mar 2010 17:03:00 GMT

摘要: 无论学习那种语言都难免要接触到文件系统，要经常和文件打交道。Java当然也不例外，有些网友觉得IO的设计很烦琐，有的时候我也有这样的感觉，其实用的熟练了，倒是觉得这个东西还是挺方便的。在介绍Java IO之前首先介绍一下非常重要的一个类File。阅读全文

轻帆向南 2010-03-30 01:03 发表评论

分享一个JTree实现资源管理器的程序代码

轻帆向南 — Mon, 29 Mar 2010 16:58:00 GMT

摘要: 做东西的时候需要实现资源管理器树形目录。正好在网上搜到这么个源代码，当边用边学习了 :) 1import java.awt.*; 2import java.awt.event.*; 3import java.io.*; 4import java.uti... 阅读全文

轻帆向南 2010-03-30 00:58 发表评论

BlogJava-轻帆向南-随笔分类-java

about String

内存不足 java.lang.OutOfMemoryError: Java heap space

关于GridBagLayout网络上一篇很好的文章

关于有模式和无模式对话框

（转）从File类开始java IO 系统介绍

分享一个JTree实现资源管理器的程序代码