《深入Java虚拟机》书中是q样描述的：(x)JVMq行时数据区的内存模型由五部分组成：(x)
?】方法区
?】堆
?】Java?/span>
?】PC寄存?/span>
?】本地方法栈
对于String s = "hello" ,它的虚拟机指令：(x)
- Java code
- 0: ldc #16; //string hello 2: astore_1 3: return
对于上面虚拟机指令，其各自的指o(h)程在《深入Java虚拟机》这hq到(l合上面实例)Q?/span>
ldc指o(h)格式Qldc,index
ldc指o(h)q程Q?/span>
要执行ldc指o(h)Qjvm首先查找index所指定的常量池入口Q在index指向的常量池入口Qjvm会(x)查找constant_integer_infoQconstant_float_info和constant_string_info入口。如果还没有q些入口Qjvm?x)解析它们。而对于上面的hahajvm?x)找到constant_string_info入口Q同Ӟ把指向被拘留String对象Q由解析该入口的q程产生Q的引用压入操作数栈?/span>
astore_1指o(h)格式Qastore_1
astore_1指o(h)q程Q?/span>
要执行astore_1指o(h)Qjvm从操作数栈顶部弹Z个引用类型或者returnaddresscd|然后该值存入由索引1指定的局部变量中,卛_引用cd或者returnaddresscd值存入局部变??/span>
return 指o(h)的过E：(x)
从方法中q回Q返回gؓ(f)void?/span>
谈一下我个h理解Q?/span>
从上面的ldc指o(h)的执行过E可以得出：(x)s的值是来自被拘留string对象Q由解析该入口的q程产生Q的引用Q即可以理解为是从被拘留string对象的引用复制而来的，故我个h的理解是s的值是存在栈当中。上面是对于s值得分析Q接着是对?hello"值的分析,我们知道Q对于string s = "hello" 其中"hello"值在javaE序~译期就定下来?jin)的。简单一点说Q就是haha的值在E序~译成class文g后，在class文g中生成了(jin)Q大家可以用ue~辑器或其它文本~辑工具在打开class文g后的字节码文件中看到q个hello|(j)。执行javaE序的过E中Q第一步是class文g生成Q然后被jvm装蝲到内存执行。那么jvm装蝲q个class到内存中Q其中的helloq个|在内存中是怎么为其开辟空间ƈ存储在哪个区域中呢？
说到q里Q我们不妨先来了(jin)解一下jvm帔R池这个结构，《深入Java虚拟机》书中有q样的描qͼ(x)
帔R?/span>
虚拟机必Mؓ(f)每个被装载的cdl护一个常量池。常量池是该类型所用到帔R的一个有序集和，包括直接帔RQstring,integer和floating point帔RQ和对其他类型，字段和方法的W号引用。对于string帔RQ它的值是在常量池中的。而jvm中的帔R池在内存当中是以表的形式存在的，对于stringcdQ有一张固定长度的constant_string_info表用来存储文字字W串|注意Q该表只存储文字字符串|不存储符号引用。说到这里，对常量池中的字符串值的存储位置应该有一个比较明?jin)的理解了(jin)?/span>
在介l完jvm帔R池的概念后，接着谈开始提到的"hello"的值的内存分布的位|。对于haha的|实际上是在class文g被jvm装蝲到内存当中ƈ被引擎在解析ldc指o(h)q执行ldc指o(h)之前Qjvm已lؓ(f)hahaq个字符串在帔R池的constant_string_info表中分配?jin)空间来存储helloq个倹{既然helloq个字符串常量存储在帔R池中Q根据《深入java虚拟机》书中描qͼ(x)帔R池是属于cd信息的一部分Q类型信息也是每一个被转蝲的类型，q个cd反映到jvm内存模型中是对应存在于jvm内存模型的方法区中，也就是这个类型信息中的常量池概念是存在于在方法区中，而方法区是在jvm内存模型中的堆中由jvm来分配的。所以，hello的值是应该是存在堆I间中的?/span>
而对于string s = new string("hello") ,它的jvm指o(h)Q?/span>
- 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
对于上面虚拟机指令，其各自的指o(h)程在《深入java虚拟机》这hq到(l合上面实例)Q?/span>
new指o(h)格式Qnew indexbyte1,indexbyte2
new指o(h)q程Q?/span>
要执行new指o(h)Qjvm通过计算(indextype1<<8)|indextype2生成一个指向常量池的无W号16位烦(ch)引。然后jvmҎ(gu)计算出的索引查找帔R池入口。该索引所指向的常量池入口必须为constant_class_info。如果该入口不存在Q那么jvm解析这个常量池入口Q该入口cd必须是类。jvm从堆中ؓ(f)新对象映像分配够大的空_(d)q将对象的实例变量设为默认倹{最后jvm指向新对象的引用objectref压入操作数栈?/span>
dup指o(h)格式Qdup
dup指o(h)q程Q?/span>
要执行dup指o(h)Qjvm复制?jin)操作数栈顶部一个字长的内容Q然后再复制内容压入栈。本指o(h)能够从操作数栈顶部复制Q何单位字长的倹{但l对不要使用它来复制操作数栈剙M两个字长(long型或double?中的一个字ѝ上面例中，卛_制引用objectrefQ这时在操作数栈存在2个引用?/span>
ldc指o(h)格式Qldc,index
ldc指o(h)q程Q?/span>
要执行ldc指o(h)Qjvm首先查找index所指定的常量池入口Q在index指向的常量池入口Qjvm会(x)查找constant_integer_infoQconstant_float_info和constant_string_info入口。如果还没有q些入口Qjvm?x)解析它们。而对于上面的haha,jvm?x)找到constant_string_info入口Q同Ӟ把指向被拘留string对象Q由解析该入口的q程产生Q的引用压入操作数栈?/span>
invokespecial指o(h)格式Qinvokespecial,indextype1,indextype2
invokespecial指o(h)q程Q对于该c而言Q该指o(h)是用来进行实例初始化Ҏ(gu)的调用。鉴于该指o(h)幅Q具体可以查阅《深入java虚拟机》中描述。上面例子中Q即通过其中一个引用调用stringcȝ构造器Q初始化对象实例Q让另一个相同的引用指向q个被初始化的对象实例，然后前一个引用弹出操作数栈?/span>
astore_1指o(h)格式Qastore_1
astore_1指o(h)q程Q?/span>
要执行astore_1指o(h)Qjvm从操作数栈顶部弹Z个引用类型或者returnaddresscd|然后该值存入由索引1指定的局部变量中,卛_引用cd或者returnaddresscd值存入局部变??/span>
return 指o(h)的过E?
从方法中q回Q返回gؓ(f)void?/span>
要执行astore_1指o(h)Qjvm从操作数栈顶部弹Z个引用类型或者returnaddresscd|然后该值存入由索引1指定的局部变量中,卛_引用cd或者returnaddresscd值存入局部变??/span>
通过上面6个指令，可以看出Qstring s = new string("hello");中的hello存储在堆I间中，而s则是在操作数栈中?/span>
上面是对s和haha值的内存情况的分析和理解Q那对于string s = new string("hello");语句,到底创徏?jin)几个对象?
我的理解Q这?hello"本n是帔R池中的一个对象，而在q行时执行new string()Ӟ常量池中的对象复制一份放到堆中，q且把堆中的q个对象的引用交ls持有。所以这条语句就创徏?个string对象?/span>
下面是一些string相关的常见问题：(x)
String中的final用法和理?/span>
final stringbuffer a = new stringbuffer("111");
final stringbuffer b = new stringbuffer("222");
a=b;//此句~译不通过
final stringbuffer a = new stringbuffer("111");
a.append("222");//~译通过
可见Qfinal只对引用??(卛_存地址)有效Q它q引用只能指向初始指向的那个对象，改变它的指向?x)导致编译期错误。至于它所指向的对象的变化Qfinal是不负责的?/span>
String 帔R池问题的几个例子
下面是几个常见例子的比较分析和理解：(x)
??/span>
- 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
分析Qjvm对于字符串常量的"+"可接，程序编译期Qjvm将帔R字符串的"+"q接优化接后的|?a" + 1来说Q经~译器优化后在class中就已经是a1。在~译期其字符串常量的值就定下来Q故上面E序最l的l果都ؓ(f)true?/span>
??/span>
- Java code
- String a = "ab"; String bb = "b"; String b = "a" + bb; System.out.println((a == b)); //result = false
分析Qjvm对于字符串引用，׃在字W串?+"q接中，有字W串引用存在Q而引用的值在E序~译期是无法定的，?a" + bb无法被编译器优化Q只有在E序q行期来动态分配ƈ连接后的新地址赋给b。所以上面程序的l果也就为false?/span>
??/span>
- Java code
- String a = "ab"; final String bb = "b"; String b = "a" + bb; System.out.println((a == b)); //result = true
分析Q和[3]中唯一不同的是bb字符串加?jin)final修饰Q对于final修饰的变量，它在~译时被解析为常量值的一个本地拷贝存储到自己的常量池中或嵌入到它的字节码中。所以此时的"a" + bb?a" + "b"效果是一L(fng)。故上面E序的结果ؓ(f)true?/span>
??/span>
- 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"; }
分析Qjvm对于字符串引用bbQ它的值在~译期无法确定，只有在程序运行期调用Ҏ(gu)后，方法的q回值和"a"来动态连接ƈ分配地址为bQ故上面E序的结果ؓ(f)false?/span>
通过上面4个例子可以得出得知：(x)
string s = "a" + "b" + "c";
q价于string s = "abc";
string a = "a";
string b = "b";
string c = "c";
string s = a + b + c;
q个׃一样了(jin)Q最l结果等于：(x)
stringbuffer temp = new stringbuffer();
temp.append(a).append(b).append(c);
string s = temp.tostring();
׃面的分析l果Q可׃难推断出string 采用q接q算W（+Q效率低下原因分析，形如q样的代码：(x)
- Java code
- public class test { public static void main (String args[]) { String s = null; for (int i = 0; i < 100; i++) { s += "a"; } } }
每做一?+ ׃生个stringbuilder对象Q然后append后就扔掉。下ơ@环再到达旉C生个stringbuilder对象Q然?append 字符Ԍ如此循环直至l束?如果我们直接采用 stringbuilder 对象q行 append 的话Q我们可以节?n - 1 ơ创建和销毁对象的旉。所以对于在循环中要q行字符串连接的应用Q一般都是用stringbuffer或stringbulider对象来进行append操作?/span>
string对象的internҎ(gu)理解和分析：(x)
- 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 } }
q里用到java里面是一个常量池的问题。对于s1+s2操作Q其实是在堆里面重新创徏?jin)一个新的对?s保存的是q个新对象在堆空间的的内容，所以s与a的值是不相{的。而当调用s.intern()Ҏ(gu)Q却可以q回s在常量池中的地址|因ؓ(f)a的值存储在帔R池中Q故s.intern和a的值相{?br />
]]>
双精度QҎ(gu)Qdouble--64位（8字节Q?-有效数字16位；
过double表示范围的，一律用BigDecimal?br />关于BigDecimal的构造，需要从String构造，切记不可由double构?br /> 即不可用 new BigDecimal(double var) [X]
而是通过 new BigDecimal(String var)
原因参?a >http://hi.baidu.com/waiting__for__you/blog/item/967206ec863751d3b21cb170.html
?br /> BigDecimal(double)是把一个doublecd十进制数构造ؓ(f)一个BigDecimal对象实例?/span>
BigDecimal(String)是把一个以String表示的BigDecimal对象构造ؓ(f)BigDecimal对象实例?/p>
?fn)惯上，对于点数我们都会(x)定义?f)double或floatQ但BigDecimal API文档中对于BigDecimal(double)有这么一D话Q?/p>
Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .10000000000000000555111512312578 27021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances notwithstanding.
The (String) constructor, on the other hand, is perfectly predictable: new BigDecimal(".1") is exactly equal to .1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one
下面对这D话做简单解释：(x)
注意Q这个构造器的结果可能会(x)有不可预知的l果。有人可能设?/span>new BigDecimal(.1){于.1是正的Q但它实际上是等?/span>.1000000000000000055511151231257827021181583404541015625Q这是Z?/span>.1不能用一?/span>double_表示的原因，因此Q这个被放进构造器中的长值ƈ不精的{于.1Q尽外观看h是相{的?/span>
然而（StringQ构造器Q则完全可预知的Q?/span>new BigDecimal(“.1”)如同期望的那L(fng)的{于.1Q因此，Q?/span>StringQ构造器是被优先推荐使用的?/span>
看下面的l果Q?/p>
System.out.println(new BigDecimal(123456789.02).toString());
System.out.println(new BigDecimal("123456789.02").toString());
输出为：(x)
123456789.01999999582767486572265625
123456789.02
现在我们知道Q如果需要精计，非要用String来够造BigDecimal不可Q?/p>
]]>
]]>
]]>
现在认识到感情这玩意儿的威力?jin)吧Q?/p>
明知自己没资本，没能力，Zq要玩这本来玩不L(fng)游戏Q?/p>
现在?c)了(jin)？你坐的住么？你想的开么？你还有能力l你的大学理想么Q?/p>
你还是放不下Q你急躁Q你无所适从Q你是急切是表现得没底气Q没思\
你颓废多长时间了(jin)Q你q想饿几KQ你q自ƺ欺人的qLC么时候？你他妈活得还是个人样么？
q有什么受不了(jin)的？多大的压力你没承受过Q?/p>
一个女生的疏离把你击垮成q样子了(jin)Q?/p>
你还认ؓ(f)自己E重Q还认ؓ(f)自己处事冷静Q还认ؓ(f)自己能面对场面不急不慌自信应对吗Q?/p>
感情q点破事儿一来，你自信跑哪去?jin)？冷静跑哪儿去了(jin)?/p>
你压根就不是谈恋qU！
你说你没l验Q没l验你跑来谈什么谈Q你冲动Q?/p>
你倒挺实在的投入进来了(jin)Qh家受伤退?jin)你现在咋办Q傻?jin)吧Q迷惘了(jin)吧？q退的回MQ?/p>
不觉得窝囊么Q?/p>
曄的你是这样子么？
你不是保持高傲着么？你不是看不惯某些人喧嚣Qw的生活Q看不惯某些人爱看热闹爱zd别h的世界里么？
你不是憧憬着一份充满默契、充满理解、彼此鼓q爱情么？
你不是最不想让别人把自己当小丑看?jin)么Q?/p>
你不是最看不惯一个男人把嘴巴涂的甜甜的去博取嬉笑么？
你不是最看不起一个男人没真材实料Q用aW掩饰空虚的么？
而你现在又在做什么呢Q?/p>
你尝试着学会(x)q些Q因Z发现没这些东西你无法在感情这个世界里获得捷径
了(jin)吧，你做不出来，你坚持不下来
你天真的认ؓ(f)彼此都会(x)自然而然的理解ƈ走到一PQ?/p>
但是她一定感受的CQ她一定能住q䆾压力Q忍耐你的节奏么Q？
你这个傻子，谁都不是你想象中的那么一_(d)谁都不能抗住太多感情带来的压力？
你把一切都想的那么自然Q一切都惌的那么美好，到头来，把所有h都害?/p>
你有些自U了(jin)
你缺乏男子汉的气?/p>
感情也一P拿的hQ也得放的下
觉得放不下，应该想办法挽回
一呛_的自我反省和U结Q有什么用Q?/p>
感情要强?/p>
感情需要承担责?/p>
感情不能只依靠心理，该有付出有付出，该有行动有行?/p>
你明白吗Q?/p>
你不该过分的自责Q给堕落扑ր口
你不是没有主动过
你不是没创造过Z(x)
哪怕你们能成功一ơ？
你们的心?yu)׃?x)d攑ּ
随缘Q随~吧Q相信缘分天注定Q谁让你们不能在一?/p>
也许人家不舍得ؓ(f)你牺牲那么多
也许人家Ҏ(gu)׃喜欢?/p>
也许
人家真的有原?/p>
你ؓ(f)何就不能痛快一点？l自׃个明的{复
下决心对自己狠一点，对别人狠一?/p>
你是个男?/p>
不好低下头向别h倾诉
那就痛快的咽下去
能争取就力争取Q给自己一个理由，l彼此一个交?/p>
你不能着?/p>
你得冷静Q真的要冷静
q不是你生活的全部，它不能占你全部的旉
量不去多想
l她一D|?/p>
让她~冲Q让她心?/p>
你觉得像个小丑一样去打扰她，是她希望看到的么Q?/p>
她不?x)觉得?ch)么？有必要么Q?/p>
不论最l结果如?/p>
要亲耛_到她的心思，她的x
l箋Q你要更加珍?/p>
分开Q你需要让彼此坦开一?/p>
男hQ最后要l自׃个清晰的交代
q叫爱吗Q?/p>
应该是?jin)?/p>
你在q?/p>
不管Ҏ(gu)么?/p>
当作她只是一时的撒娇生气?/p>
{她
冷静的等?/p>
如果接受Q放开你的全部Q像个男人的Pl她q福
如果dQ做到彼此的坦诚Q祝她
不管怎样
q些天要对自pU！
好好面对生活
不能消极堕落
千万不能Q?br />
-------->]]>
]]>
非模态对话框与模态对话框相比有下列不同之处：(x)
非模态对话框的模板必d有Visible风格Q否则对话框不可见Q而模态对话框则无需
讄该项风格。更保险的办法是调用CWnd::ShowWindow(SW_SHOW)来显C对话框Q而不?nbsp;
对话框是否具有Visible风格?nbsp;
非模态对话框对象是用new操作W在堆中动态创建的Q而不是以成员变量的Ş式嵌入到?nbsp;
的对象中或以局部变量的形式构徏在堆栈上。通常应在对话框的拥有者窗口类内声明一
个指向对话框cȝ指针成员变量Q通过该指针可讉K对话框对象?nbsp;
通过调用CDialog::Create函数来启动对话框Q而不是CDialog::DoModalQ这是模态对?nbsp;
框的关键所在。由于Create函数不会(x)启动新的消息循环Q对话框与应用程序共用同一?nbsp;
消息循环Q这样对话框׃?x)垄断用L(fng)输入。Create在显CZ(jin)对话框后q卌回，
而DoModal是在对话框被关闭后才q回的。众所周知Q在MFCE序中，H口对象的生存期
应长于对应的H口Q也是_(d)不能在未关闭屏幕上窗口的情况下先把对应的H口对象
删除掉。由于在Createq回后，不能定对话框是否已关闭Q这样也无法确定对话框
对象的生存期Q因此只好在堆中构徏对话框对象，而不能以局部变量的形式来构Z?nbsp;
必须调用CWnd::DestroyWindow而不是CDialog::EndDialog来关闭非模态对话框。调用C
Wnd::DestroyWindow是直接删除窗口的一般方法。由于缺省的CDialog::OnOK和CDialog
∶:OnCancel函数均调用EndDialogQ故E序员必ȝ写自qOnOK和OnCancel函数q且?nbsp;
函数中调用DestroyWindow来关闭对话框?nbsp;
因ؓ(f)是用new操作W构建非模态对话框对象Q因此必d对话框关闭后Q用delete操作W?nbsp;
删除对话框对象。在屏幕上一个窗口被删除后，框架?x)调用CWnd::PostNcDestroyQ这?nbsp;
一个虚拟函敎ͼE序可以在该函数中完成删除窗口对象的工作Q具体代码如?nbsp;
void CModelessDialog::PostNcDestroy
{
delete this; //删除对象本n
}
q样Q在删除屏幕上的对话框后Q对话框对象被自动删除。拥有者对象就不必昑ּ?nbsp;
调用delete来删除对话框对象?jin)?nbsp;
必须有一个标志表明非模态对话框是否是打开的。这样做的原因是用户有可能在打开一
个模态对话框的情况下Q又一ơ选择打开命o(h)。程序根据标志来军_是打开一个新的对
话框Q还是仅仅把原来打开的对话框ȀzR通常可以用拥有者窗口中的指向对话框对象
的指针作U标志，当对话框关闭Ӟl该指针赋NULL|以表明对话框对象已不?nbsp;
在了(jin)?
]]>
]]>
]]>