??xml version="1.0" encoding="utf-8" standalone="yes"?>亚州av电影免费在线观看,激情都市亚洲,神马电影在线观看http://www.aygfsteel.com/calvinlau/category/39179.html技术储备,从这里开?/description>zh-cnMon, 05 Oct 2009 10:15:24 GMTMon, 05 Oct 2009 10:15:24 GMT60zz finally的小Ҏ?/title><link>http://www.aygfsteel.com/calvinlau/articles/296745.html</link><dc:creator>calvinlau</dc:creator><author>calvinlau</author><pubDate>Mon, 28 Sep 2009 03:09:00 GMT</pubDate><guid>http://www.aygfsteel.com/calvinlau/articles/296745.html</guid><wfw:comment>http://www.aygfsteel.com/calvinlau/comments/296745.html</wfw:comment><comments>http://www.aygfsteel.com/calvinlau/articles/296745.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.aygfsteel.com/calvinlau/comments/commentRss/296745.html</wfw:commentRss><trackback:ping>http://www.aygfsteel.com/calvinlau/services/trackbacks/296745.html</trackback:ping><description><![CDATA[<span style="font-size: large;">http://zangxt.javaeye.com/blog/421508<br /> <br /> try/catch/finally语句下,finally子句是肯定会执行的。但是很多h做不同的试Q却得出了不同的l论?/span> <p><span style="font-size: large;">具体的原理最好是ȝ《深入java虚拟机》,里面对jsr、ret{几个指令做了详l的说明。这里不深入分析Q而仅仅是从表现Ş式上看一下finally的特征?/span></p> <p><span style="font-size: large;">代码Q?/span></p> <p><span style="font-size: large;">   <pre name="code" class="java">/*<br /> * author: Zang XT<br /> */<br /> <br /> public class TestFinal {<br /> public static void main(String[] args) {<br /> System.out.println("test1:" + testFinal1());<br /> System.out.println("test2:" + testFinal2());<br /> System.out.println("test3:" + testFinal3());<br /> System.out.println("test4:" + testFinal4());<br /> }<br /> <br /> static int testFinal1() {<br /> int i = 1;<br /> try {<br /> return i;<br /> } finally {<br /> System.out.println("in testFinal1():finally 肯定会被执行的!");<br /> i = 48;<br /> }<br /> }<br /> <br /> static String testFinal2() {<br /> String str = "try";<br /> try {<br /> return str;<br /> } finally {<br /> System.out.println("in testFinal2():finally 肯定会被执行的!");<br /> str = "finally";<br /> }<br /> }<br /> <br /> static StringBuilder testFinal3() {<br /> StringBuilder build = new StringBuilder("try ");<br /> try {<br /> return build;<br /> } finally {<br /> System.out.println("in testFinal3():finally 肯定会被执行的!");<br /> build.append("finally");<br /> build = new StringBuilder("你猜我是谁!");<br /> }<br /> }<br /> <br /> static String testFinal4() {<br /> try {<br /> return "return in try";<br /> } finally {<br /> System.out.println("in testFinal4():finally 肯定会被执行的!");<br /> return "return in finally";<br /> }<br /> }<br /> }<br /> <br /> </pre> <font size="5"> <p> </p> </font></span></p> <p> </p> <p><span style="font-size: large;">输出是:</span></p> <p><span style="font-size: large;">in testFinal1():finally 肯定会被执行的!</span></p> <p><span style="font-size: large;">test1:1</span></p> <p><span style="font-size: large;">in testFinal2():finally 肯定会被执行的!</span></p> <p><span style="font-size: large;">test2:try</span></p> <p><span style="font-size: large;">in testFinal3():finally 肯定会被执行的!</span></p> <p><span style="font-size: large;">test3:try finally</span></p> <p><span style="font-size: large;">in testFinal4():finally 肯定会被执行的!</span></p> <p><span style="font-size: large;">test4:return in finally</span></p> <div><span style="font-size: large;">     l论很明显,finally的语句确实执行了Q而且肯定是在Ҏreturn之前执行的,而且Q如果finally中有return语句的话Q方法直接结 束。这里需要注意的只有一点:在try中的return语句会将q回l果值压栈,然后转入到finally子过E,{到finally子过E执行完毕之? Q没有returnQ,再返回?/span></div> <div><span style="font-size: large;">下面具体?个例子:</span></div> <div><span style="font-size: large;">      在testFinal1()中,return i;会将l果i的|也就?压入栈。即使在finally中将i修改了(i=48Q,也不回对已经压入栈里?造成M影响?/span></div> <div><span style="font-size: large;">      在testFinal2()中,return str;str的内容压入栈Q比如我们假设str的内容ؓ0x108(只是一个地址?,通过q个地址值我们能扑ֈ"try"Q那栈里的内容就? 0x108。执行str = "finally"Q这时候strq个变量的内容可能变?x237了,q是?finally"的地址。方法调用结束后Q返回的是什么?return? 压入栈里?x108。所以在打印l果Ӟ我们打印的是通过0x108扑ֈ的字W串"try"?/span></div> <div><span style="font-size: large;">      在testFinal3()中,return 压栈的是buildq个变量的|比如?x3579Q通过q个值我们可以找到StringBuilder对象。finally语句块中对这个对象的内容 q行了修攏Vbuild = new StringBuilder("你猜我是谁!");让build变量指向了一个新的对象,q时候build的值可能是0x4579了。但是,别忘了,原来 的StringBuilder对象仍然?x3579处,而我们压栈的正是0x3579啊!Ҏq回后,我们得到的返回?x3579Q通过q个引用值找 到相应的StringBuilder对象Q所以打印的l果是test3:try finally?/span></div> <div><span style="font-size: large;">      在testFinal4()中,finally有return语句Q直接返回,Ҏl束?/span></div> <div><span style="font-size: large;">      Z么不同的人有不同的结论?关键是没有正理解压栈的是什么东ѝ其实初学java的时候,如果理解了变量是什么,q区分引用和对象本n׃会得到错误的l论了。再有,如果理解java中,Ҏ调用都是采用传值模式的话,q里也就cM的可以明白了?/span></div> <img src ="http://www.aygfsteel.com/calvinlau/aggbug/296745.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.aygfsteel.com/calvinlau/" target="_blank">calvinlau</a> 2009-09-28 11:09 <a href="http://www.aygfsteel.com/calvinlau/articles/296745.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>HashMap & Hashtablehttp://www.aygfsteel.com/calvinlau/articles/267242.htmlcalvinlaucalvinlauThu, 23 Apr 2009 14:20:00 GMThttp://www.aygfsteel.com/calvinlau/articles/267242.htmlhttp://www.aygfsteel.com/calvinlau/comments/267242.htmlhttp://www.aygfsteel.com/calvinlau/articles/267242.html#Feedback0http://www.aygfsteel.com/calvinlau/comments/commentRss/267242.htmlhttp://www.aygfsteel.com/calvinlau/services/trackbacks/267242.html
1、Hashtable是Dictionary的子c,HashMap是Map接口的一个实现类Q?br />
2?span style="color: red;">Hashtable中的Ҏ是同步的Q而HashMap中的Ҏ在缺省情况下是非同步?/span>。即是说Q在多线E应用程序中Q不用专门的操作安全地可以使用Hashtable了;而对? HashMapQ则需要额外的同步机制。但HashMap的同步问题可通过Collections的一个静态方法得到解冻I
Map Collections.synchronizedMap(Map m)
q个Ҏq回一个同步的MapQ这个Map装了底层的HashMap的所有方法,使得底层的HashMap即是在多线E的环境中也是安全的?br />
3?span style="color: red;">在HashMap中,null可以作ؓ?/span>Q这L键只有一个;可以有一个或多个键所对应的gؓnull。当get()Ҏq回null值时Q即可以表示 HashMap中没有该键,也可以表C键所对应的gؓnull。因此,在HashMap中不能由get()Ҏ来判断HashMap中是否存在某个键Q? 而应该用containsKey()Ҏ来判断?

4、其底层的实现机制不同,HashMap的访问速度要快于HashtableQ因为它不需要进行同步检验,在非多线E环境中使用HashMap代替Hashtable

补充Q?br /> 5、HashMap的默认初始容量是16QHashtable的默认初始容量是11
6、keySet()、values() 、entrySet() 支持元素的删除,但是不支持元素的d

==================== 分割U:JDK5帮助文档的描q?==================

HashMap:

Z哈希表的 Map 接口的实现。此实现提供所有可选的映射操作Q?span style="color: red;">q允怋?null 值和 null 键。(除了不同步和允许使用 null 之外QHashMap cM Hashtable 大致相同。)此类不保证映的序Q特别是它不保证该顺序恒久不变?nbsp;


此实现假定哈希函数将元素正确分布在各桶之_可ؓ基本操作Qget ?putQ提供稳定的性能?span style="color: red;">q代集合视图所需的时间与 HashMap 实例?#8220;定w”Q桶的数量)及其大小Q键-值映关pLQ的和成比例。所以,如果q代性能很重要,则不要将初始定w讄得太高(或将加蝲因子讄得太低)?

HashMap 的实例有两个参数影响其性能Q初始容量和加蝲因子。容量是哈希表中桶的数量Q初始容量只是哈希表在创建时的容量。加载因? 是哈希表在其定w自动增加之前可以辑ֈ多满的一U尺度。当哈希表中的条目数出了加载因子与当前定w的乘U时Q通过调用 rehash Ҏ容量翻倍?

通常Q?span style="color: rgb(32, 88, 255);">默认加蝲因子 (.75) 在时间和I间成本上寻求一U折?/span>? 加蝲因子q高虽然减少了空间开销Q但同时也增加了查询成本Q在大多?HashMap cȝ操作中,包括 get ?put 操作Q都反映了这一点)。在讄初始定w时应该考虑到映中所需的条目数及其加蝲因子Q以便最大限度地降低 rehash 操作ơ数。如果初始容量大于最大条目数除以加蝲因子Q则不会发生 rehash 操作?

如果很多映射关系要存储在 HashMap 实例中,则相对于按需执行自动?rehash 操作以增大表的容量来_使用_大的初始定w创徏它将使得映射关系能更有效地存储?

注意Q?span style="color: rgb(255, 0, 0);">此实C是同步的。如果多个线E同时访问此映射Q而其中至一个线E从l构上修改了该映,则它必须保持外部同步。(l构上的修改是指d或删除一个或多个映射关系的操作;仅改变与实例已经包含的键兌的g是结构上的修?/span>。)q一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在q样的对象,则应该?Collections.synchronizedMap Ҏ?#8220;包装”该映。最好在创徏时完成这一操作Q以防止Ҏ进行意外的不同步访问,如下所C:

 Map m = Collections.synchronizedMap(new HashMap(...));
 由所有此cȝ“集合视图Ҏ”所q回的P代器都是快速失败的Q? 在P代器创徏之后Q如果从l构上对映射q行修改Q除非通过q代器自w的 remove ?add ҎQ其他Q何时间Q何方式的修改QP代器都将抛出 ConcurrentModificationException。因此,面对q发的修改,q代器很快就会完全失败,而不冒在来不确定的旉L发生? 定行ؓ的风险?

注意QP代器的快速失败行Z能得C证,一般来_存在不同步的q发修改Ӟ不可能作ZQ何坚决的保证。快速失败P代器最大努力抛? ConcurrentModificationException。因此,~写依赖于此异常E序的方式是错误的,正确做法是:q代器的快速失败行为应该仅 用于程序错误?nbsp;


Hashtable:

此类实现一个哈希表Q该哈希表将键映到相应的倹{?span style="color: rgb(255, 0, 0);">M?null 对象都可以用作键或?/span>?br />
Z成功地在哈希表中存储和检索对象,用作键的对象必须实现 hashCode Ҏ?equals Ҏ?br />
Hashtable 的实例有两个参数影响其性能Q初始容量和加蝲因子。容量是哈希表中桶的数量Q初始容量就是哈希表创徏时的定w。注意,哈希表的状态ؓ openQ在发生“哈希冲突”的情况下Q单个桶会存储多个条目,q些条目必须按顺序搜索。加载因子是对哈希表在其定w自动增加之前可以辑ֈ多满的一个尺 度。初始容量和加蝲因子q两个参数只是对该实现的提示。关于何时以及是否调?rehash Ҏ的具体细节则依赖于该实现?br />
通常Q默认加载因?.75)在时间和I间成本上寻求一U折街加载因子过高虽然减了I间开销Q但同时也增加了查找某个条目的时_在大多数 Hashtable 操作中,包括 get ?put 操作Q都反映了这一点)?br />
初始定w主要控制I间消耗与执行 rehash 操作所需要的旉损耗之间的q。如果初始容量大于Hashtable 所包含的最大条目数除以加蝲因子Q则永远不会发生 rehash 操作。但是,初始容量设|太高可能会费I间?br />
如果很多条目要存储在一?Hashtable 中,那么与根据需要执行自?rehashing 操作来增大表的容量的做法相比Q用够大的初始容量创建哈希表或许可以更有效地插入条目?br />
下面q个CZ创徏了一个数字的哈希表。它数字的名称用作键:

1 Hashtable numbers = new Hashtable();
2 numbers.put("one"new Integer(1));
3 numbers.put("two"new Integer(2));
4 numbers.put("three"new Integer(3));

要检索一个数字,可以使用以下代码Q?

Integer n = (Integer)numbers.get("two");
if (n != null) {
    System.out.println(
"two = " + n);
}


 ?Java 2 q_ v1.2 以来Q此cdl改qؓ可以实现 MapQ因此它变成?Java Collections Framework 的一部分。与新集合的实现不同QHashtable 是同步的?br />
pP代器q回?Iterator 和由所?Hashtable ?#8220;collection 视图Ҏ”q回?Collection ? listIterator Ҏ都是快速失?的:在创?Iterator 之后Q如果从l构上对 Hashtable q行修改Q除非通过 Iterator 自n的移除或dҎQ否则在M旉以Q何方式对其进行修改,Iterator 都将抛出 ConcurrentModificationException。因此,面对q发的修改,Iterator 很快׃完全p|Q而不冒在来某个不确定的旉发生L不确定行为的风险。由 Hashtable 的键和值方法返回的 Enumeration ? 是快速失败的?

注意QP代器的快速失败行为无法得C证,因ؓ一般来_不可能对是否出现不同步ƈ发修改做ZQ何硬性保证。快速失败P代器会尽最大努力抛? ConcurrentModificationException。因此,为提高这cP代器的正性而编写一个依赖于此异常的E序是错误做法:q代器的? 速失败行为应该仅用于程序错误?



calvinlau 2009-04-23 22:20 发表评论
]]>
HashMap & Hashtablehttp://www.aygfsteel.com/calvinlau/articles/267238.htmlcalvinlaucalvinlauThu, 23 Apr 2009 13:49:00 GMThttp://www.aygfsteel.com/calvinlau/articles/267238.htmlhttp://www.aygfsteel.com/calvinlau/comments/267238.htmlhttp://www.aygfsteel.com/calvinlau/articles/267238.html#Feedback0http://www.aygfsteel.com/calvinlau/comments/commentRss/267238.htmlhttp://www.aygfsteel.com/calvinlau/services/trackbacks/267238.html
1、Hashtable是Dictionary的子c,HashMap是Map接口的一个实现类Q?br />
2?span style="color: red;">Hashtable中的Ҏ是同步的Q而HashMap中的Ҏ在缺省情况下是非同步?/span>。即是说Q在多线E应用程序中Q不用专门的操作安全地可以使用Hashtable了;而对? HashMapQ则需要额外的同步机制。但HashMap的同步问题可通过Collections的一个静态方法得到解冻I
Map Collections.synchronizedMap(Map m)
q个Ҏq回一个同步的MapQ这个Map装了底层的HashMap的所有方法,使得底层的HashMap即是在多线E的环境中也是安全的?br />
3?span style="color: red;">在HashMap中,null可以作ؓ?/span>Q这L键只有一个;可以有一个或多个键所对应的gؓnull。当get()Ҏq回null值时Q即可以表示 HashMap中没有该键,也可以表C键所对应的gؓnull。因此,在HashMap中不能由get()Ҏ来判断HashMap中是否存在某个键Q? 而应该用containsKey()Ҏ来判断?

4、其底层的实现机制不同,HashMap的访问速度要快于HashtableQ因为它不需要进行同步检验,在非多线E环境中使用HashMap代替Hashtable

==================== 分割U:JDK5帮助文档的描q?==================

HashMap:

Z哈希表的 Map 接口的实现。此实现提供所有可选的映射操作Q?span style="color: red;">q允怋?null 值和 null 键。(除了不同步和允许使用 null 之外QHashMap cM Hashtable 大致相同。)此类不保证映的序Q特别是它不保证该顺序恒久不变?nbsp;


此实现假定哈希函数将元素正确分布在各桶之_可ؓ基本操作Qget ?putQ提供稳定的性能?span style="color: red;">q代集合视图所需的时间与 HashMap 实例?#8220;定w”Q桶的数量)及其大小Q键-值映关pLQ的和成比例。所以,如果q代性能很重要,则不要将初始定w讄得太高(或将加蝲因子讄得太低)?

HashMap 的实例有两个参数影响其性能Q初始容量和加蝲因子。容量是哈希表中桶的数量Q初始容量只是哈希表在创建时的容量。加载因?是哈希表在其定w自动增加之前可以辑ֈ多满的一U尺度。当哈希表中的条目数出了加载因子与当前定w的乘U时Q通过调用 rehash Ҏ容量翻倍?

通常Q?span style="color: #2058ff;">默认加蝲因子 (.75) 在时间和I间成本上寻求一U折?/span>。加载因子过高虽然减了I间开销Q但同时也增加了查询成本Q在大多?HashMap cȝ操作中,包括 get ?put 操作Q都反映了这一点)。在讄初始定w时应该考虑到映中所需的条目数及其加蝲因子Q以便最大限度地降低 rehash 操作ơ数。如果初始容量大于最大条目数除以加蝲因子Q则不会发生 rehash 操作?

如果很多映射关系要存储在 HashMap 实例中,则相对于按需执行自动?rehash 操作以增大表的容量来_使用_大的初始定w创徏它将使得映射关系能更有效地存储?

注意Q?span style="color: #ff0000;">此实C是同步的。如果多个线E同时访问此映射Q而其中至一个线E从l构上修改了该映,则它必须保持外部同步。(l构上的修改是指d或删除一个或多个映射关系的操作;仅改变与实例已经包含的键兌的g是结构上的修?/span>。)q一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在q样的对象,则应该?Collections.synchronizedMap Ҏ?#8220;包装”该映。最好在创徏时完成这一操作Q以防止Ҏ进行意外的不同步访问,如下所C:

 Map m = Collections.synchronizedMap(new HashMap(...));
 由所有此cȝ“集合视图Ҏ”所q回的P代器都是快速失败的Q在q代器创Z后,如果从结构上Ҏ进行修改,除非通过q代器自w的 remove ?add ҎQ其他Q何时间Q何方式的修改QP代器都将抛出 ConcurrentModificationException。因此,面对q发的修改,q代器很快就会完全失败,而不冒在来不确定的旉L发生不确定行为的风险?

注意QP代器的快速失败行Z能得C证,一般来_存在不同步的q发修改Ӟ不可能作ZQ何坚决的保证。快速失败P代器最大努力抛?ConcurrentModificationException。因此,~写依赖于此异常E序的方式是错误的,正确做法是:q代器的快速失败行为应该仅用于程序错误?nbsp;


Hashtable:

此类实现一个哈希表Q该哈希表将键映到相应的倹{?span style="color: #ff0000;">M?null 对象都可以用作键或?/span>?br />
Z成功地在哈希表中存储和检索对象,用作键的对象必须实现 hashCode Ҏ?equals Ҏ?br />
Hashtable 的实例有两个参数影响其性能Q初始容量和加蝲因子。容量是哈希表中桶的数量Q初始容量就是哈希表创徏时的定w。注意,哈希表的状态ؓ openQ在发生“哈希冲突”的情况下Q单个桶会存储多个条目,q些条目必须按顺序搜索。加载因子是对哈希表在其定w自动增加之前可以辑ֈ多满的一个尺度。初始容量和加蝲因子q两个参数只是对该实现的提示。关于何时以及是否调?rehash Ҏ的具体细节则依赖于该实现?br />
通常Q默认加载因?.75)在时间和I间成本上寻求一U折街加载因子过高虽然减了I间开销Q但同时也增加了查找某个条目的时_在大多数 Hashtable 操作中,包括 get ?put 操作Q都反映了这一点)?br />
初始定w主要控制I间消耗与执行 rehash 操作所需要的旉损耗之间的q。如果初始容量大于Hashtable 所包含的最大条目数除以加蝲因子Q则永远不会发生 rehash 操作。但是,初始容量设|太高可能会费I间?br />
如果很多条目要存储在一?Hashtable 中,那么与根据需要执行自?rehashing 操作来增大表的容量的做法相比Q用够大的初始容量创建哈希表或许可以更有效地插入条目?br />
下面q个CZ创徏了一个数字的哈希表。它数字的名称用作键:

1 Hashtable numbers = new Hashtable();
2 numbers.put("one"new Integer(1));
3 numbers.put("two"new Integer(2));
4 numbers.put("three"new Integer(3));

要检索一个数字,可以使用以下代码Q?

Integer n = (Integer)numbers.get("two");
if (n != null) {
    System.out.println(
"two = " + n);
}


 ?Java 2 q_ v1.2 以来Q此cdl改qؓ可以实现 MapQ因此它变成?Java Collections Framework 的一部分。与新集合的实现不同QHashtable 是同步的?br />
pP代器q回?Iterator 和由所?Hashtable ?#8220;collection 视图Ҏ”q回?Collection ?listIterator Ҏ都是快速失?的:在创?Iterator 之后Q如果从l构上对 Hashtable q行修改Q除非通过 Iterator 自n的移除或dҎQ否则在M旉以Q何方式对其进行修改,Iterator 都将抛出 ConcurrentModificationException。因此,面对q发的修改,Iterator 很快׃完全p|Q而不冒在来某个不确定的旉发生L不确定行为的风险。由 Hashtable 的键和值方法返回的 Enumeration ?是快速失败的?

注意QP代器的快速失败行为无法得C证,因ؓ一般来_不可能对是否出现不同步ƈ发修改做ZQ何硬性保证。快速失败P代器会尽最大努力抛?ConcurrentModificationException。因此,为提高这cP代器的正性而编写一个依赖于此异常的E序是错误做法:q代器的快速失败行为应该仅用于程序错误?



calvinlau 2009-04-23 21:49 发表评论
]]>
վ֩ģ壺 ˶| ն| | üɽ| Ƽ| | ع| ͼƬ| | | ¬| ˹| | | | ƽԶ| | | | ɽ| | | ¡| Ͱ| ɽ| | »| | | ذ| | | | | | | ʯ| | ƽ| | ͬ|