2013年6月16日
http://www.oracle.com/technetwork/java/archive-139210.html
javap -g Foo.java (-g 生成行號(hào))
javap -c -s -l -verbose Foo
裝箱：從基本類型轉(zhuǎn)換成Object類型，稱之為裝箱；***拆箱：從Object轉(zhuǎn)換乘基本類型的操作，稱之為拆箱。 這個(gè)操作在反射過(guò)程中用的比較的多。 裝箱：在堆中建立一個(gè)Object實(shí)例，把你指定的值復(fù)制成去；***拆箱：判別引用指向的堆中信息是否是要拆成的類型，是取出堆中值送給棧中變量，否則報(bào)異常
//在-128~127 之外的數(shù) Integer num1 = 297; Integer num2 = 297; System.out.println("num1==num2: "+(num1==num2)); // 在-128~127 之內(nèi)的數(shù) Integer num3 = 97; Integer num4 = 97; System.out.println("num3==num4: "+(num3==num4)); 打印的結(jié)果是：num1==num2: false num3==num4: true
很奇怪吧：這就歸結(jié)于java對(duì)于Integer與int的自動(dòng)裝箱與拆箱的設(shè)計(jì)，是一種模式：叫享元模式（flyweight） 為了加大對(duì)簡(jiǎn)單數(shù)字的重利用，java定義：在自動(dòng)裝箱時(shí)對(duì)于值從–128到127之間的值，它們被裝箱為Integer對(duì)象后，會(huì)存在內(nèi)存中被重用，始終只存在一個(gè)對(duì)象 而如果超過(guò)了從–128到127之間的值，被裝箱后的Integer對(duì)象并不會(huì)被重用，即相當(dāng)于每次裝箱時(shí)都新建一個(gè) Integer對(duì)象；明白了吧 以上的現(xiàn)象是由于使用了自動(dòng)裝箱所引起的，如果你沒(méi)有使用自動(dòng)裝箱，而是跟一般類一樣，用new來(lái)進(jìn)行實(shí)例化，就會(huì)每次new就都一個(gè)新的對(duì)象；
1. Java中的泛型是什么 ? 使用泛型的好處是什么?
這是在各種Java泛型面試中，一開(kāi)場(chǎng)你就會(huì)被問(wèn)到的問(wèn)題中的一個(gè)，主要集中在初級(jí)和中級(jí)面試中。那些擁有Java1.4或更早版本的開(kāi)發(fā)背景的人都知道，在集合中存儲(chǔ)對(duì)象并在使用前進(jìn)行類型轉(zhuǎn)換是多么的不方便。泛型防止了那種情況的發(fā)生。它提供了編譯期的類型安全，確保你只能把正確類型的對(duì)象放入集合中，避免了在運(yùn)行時(shí)出現(xiàn)ClassCastException。
2. Java的泛型是如何工作的 ? 什么是類型擦除 ?
這是一道更好的泛型面試題。泛型是通過(guò)類型擦除來(lái)實(shí)現(xiàn)的，編譯器在編譯時(shí)擦除了所有類型相關(guān)的信息，所以在運(yùn)行時(shí)不存在任何類型相關(guān)的信息。例如List<String>在運(yùn)行時(shí)僅用一個(gè)List來(lái)表示。這樣做的目的，是確保能和Java 5之前的版本開(kāi)發(fā)二進(jìn)制類庫(kù)進(jìn)行兼容。你無(wú)法在運(yùn)行時(shí)訪問(wèn)到類型參數(shù)，因?yàn)榫幾g器已經(jīng)把泛型類型轉(zhuǎn)換成了原始類型。根據(jù)你對(duì)這個(gè)泛型問(wèn)題的回答情況，你會(huì)得到一些后續(xù)提問(wèn)，比如為什么泛型是由類型擦除來(lái)實(shí)現(xiàn)的或者給你展示一些會(huì)導(dǎo)致編譯器出錯(cuò)的錯(cuò)誤泛型代碼。請(qǐng)閱讀我的Java中泛型是如何工作的來(lái)了解更多信息。
3. 什么是泛型中的限定通配符和非限定通配符 ?
這是另一個(gè)非常流行的Java泛型面試題。限定通配符對(duì)類型進(jìn)行了限制。有兩種限定通配符，一種是<? extends T>它通過(guò)確保類型必須是T的子類來(lái)設(shè)定類型的上界，另一種是<? super T>它通過(guò)確保類型必須是T的父類來(lái)設(shè)定類型的下界。泛型類型必須用限定內(nèi)的類型來(lái)進(jìn)行初始化，否則會(huì)導(dǎo)致編譯錯(cuò)誤。另一方面<?>表示了非限定通配符，因?yàn)?lt;?>可以用任意類型來(lái)替代。更多信息請(qǐng)參閱我的文章泛型中限定通配符和非限定通配符之間的區(qū)別。
4. List<? extends T>和List <? super T>之間有什么區(qū)別 ?
這和上一個(gè)面試題有聯(lián)系，有時(shí)面試官會(huì)用這個(gè)問(wèn)題來(lái)評(píng)估你對(duì)泛型的理解，而不是直接問(wèn)你什么是限定通配符和非限定通配符。這兩個(gè)List的聲明都是限定通配符的例子，List<? extends T>可以接受任何繼承自T的類型的List，而List<? super T>可以接受任何T的父類構(gòu)成的List。例如List<? extends Number>可以接受List<Integer>或List<Float>。在本段出現(xiàn)的連接中可以找到更多信息。
5. 如何編寫(xiě)一個(gè)泛型方法，讓它能接受泛型參數(shù)并返回泛型類型?
編寫(xiě)泛型方法并不困難，你需要用泛型類型來(lái)替代原始類型，比如使用T, E or K,V等被廣泛認(rèn)可的類型占位符。泛型方法的例子請(qǐng)參閱Java集合類框架。最簡(jiǎn)單的情況下，一個(gè)泛型方法可能會(huì)像這樣:
public V put(K key, V value) { return cache.put(key, value); } 6. Java中如何使用泛型編寫(xiě)帶有參數(shù)的類?
這是上一道面試題的延伸。面試官可能會(huì)要求你用泛型編寫(xiě)一個(gè)類型安全的類，而不是編寫(xiě)一個(gè)泛型方法。關(guān)鍵仍然是使用泛型類型來(lái)代替原始類型，而且要使用JDK中采用的標(biāo)準(zhǔn)占位符。
7. 編寫(xiě)一段泛型程序來(lái)實(shí)現(xiàn)LRU緩存?
對(duì)于喜歡Java編程的人來(lái)說(shuō)這相當(dāng)于是一次練習(xí)。給你個(gè)提示，LinkedHashMap可以用來(lái)實(shí)現(xiàn)固定大小的LRU緩存，當(dāng)LRU緩存已經(jīng)滿了的時(shí)候，它會(huì)把最老的鍵值對(duì)移出緩存。LinkedHashMap提供了一個(gè)稱為removeEldestEntry()的方法，該方法會(huì)被put()和putAll()調(diào)用來(lái)刪除最老的鍵值對(duì)。當(dāng)然，如果你已經(jīng)編寫(xiě)了一個(gè)可運(yùn)行的JUnit測(cè)試，你也可以隨意編寫(xiě)你自己的實(shí)現(xiàn)代碼。
8. 你可以把List<String>傳遞給一個(gè)接受List<Object>參數(shù)的方法嗎？
對(duì)任何一個(gè)不太熟悉泛型的人來(lái)說(shuō)，這個(gè)Java泛型題目看起來(lái)令人疑惑，因?yàn)檎Э雌饋?lái)String是一種Object，所以List<String>應(yīng)當(dāng)可以用在需要List<Object>的地方，但是事實(shí)并非如此。真這樣做的話會(huì)導(dǎo)致編譯錯(cuò)誤。如果你再深一步考慮，你會(huì)發(fā)現(xiàn)Java這樣做是有意義的，因?yàn)長(zhǎng)ist<Object>可以存儲(chǔ)任何類型的對(duì)象包括String, Integer等等，而List<String>卻只能用來(lái)存儲(chǔ)Strings。
List<Object> objectList; List<String> stringList; objectList = stringList; //compilation error incompatible types
9. Array中可以用泛型嗎?
這可能是Java泛型面試題中最簡(jiǎn)單的一個(gè)了，當(dāng)然前提是你要知道Array事實(shí)上并不支持泛型，這也是為什么Joshua Bloch在Effective Java一書(shū)中建議使用List來(lái)代替Array，因?yàn)長(zhǎng)ist可以提供編譯期的類型安全保證，而Array卻不能。
10. 如何阻止Java中的類型未檢查的警告?
如果你把泛型和原始類型混合起來(lái)使用，例如下列代碼，Java 5的javac編譯器會(huì)產(chǎn)生類型未檢查的警告，例如
List<String> rawList = new ArrayList() 注意: Hello.java使用了未檢查或稱為不安全的操作;
這種警告可以使用@SuppressWarnings("unchecked")注解來(lái)屏蔽。
Java泛型面試題補(bǔ)充更新:
我手頭又拿到了幾個(gè)Java泛型面試題跟大家分享下，這幾道題集中在泛型類型和原始類型的區(qū)別上，以及我們是否可以用Object來(lái)代替限定通配符的使用等等：
Java中List<Object>和原始類型List之間的區(qū)別?
原始類型和帶參數(shù)類型<Object>之間的主要區(qū)別是，在編譯時(shí)編譯器不會(huì)對(duì)原始類型進(jìn)行類型安全檢查，卻會(huì)對(duì)帶參數(shù)的類型進(jìn)行檢查，通過(guò)使用Object作為類型，可以告知編譯器該方法可以接受任何類型的對(duì)象，比如String或Integer。這道題的考察點(diǎn)在于對(duì)泛型中原始類型的正確理解。它們之間的第二點(diǎn)區(qū)別是，你可以把任何帶參數(shù)的類型傳遞給原始類型List，但卻不能把List<String>傳遞給接受List<Object>的方法，因?yàn)闀?huì)產(chǎn)生變異錯(cuò)誤。更多詳細(xì)信息請(qǐng)參閱Java中的泛型是如何工作的。
Java中List<?>和List<Object>之間的區(qū)別是什么?
這道題跟上一道題看起來(lái)很像，實(shí)質(zhì)上卻完全不同。List<?> 是一個(gè)未知類型的List，而List<Object>其實(shí)是任意類型的List。你可以把List<String>, List<Integer>賦值給List<?>，卻不能把List<String>賦值給List<Object>。
List<?> listOfAnyType; List<Object> listOfObject = new ArrayList<Object>(); List<String> listOfString = new ArrayList<String>(); List<Integer> listOfInteger = new ArrayList<Integer>(); listOfAnyType = listOfString; //legal listOfAnyType = listOfInteger; //legal listOfObjectType = (List<Object>) listOfString; //compiler error - in-convertible types
想了解更多關(guān)于通配符的信息請(qǐng)查看Java中的泛型通配符示例
List<String>和原始類型List之間的區(qū)別.
該題類似于“原始類型和帶參數(shù)類型之間有什么區(qū)別”。帶參數(shù)類型是類型安全的，而且其類型安全是由編譯器保證的，但原始類型List卻不是類型安全的。你不能把String之外的任何其它類型的Object存入String類型的List中，而你可以把任何類型的對(duì)象存入原始List中。使用泛型的帶參數(shù)類型你不需要進(jìn)行類型轉(zhuǎn)換，但是對(duì)于原始類型，你則需要進(jìn)行顯式的類型轉(zhuǎn)換。
List listOfRawTypes = new ArrayList(); listOfRawTypes.add("abc"); listOfRawTypes.add(123); //編譯器允許這樣 - 運(yùn)行時(shí)卻會(huì)出現(xiàn)異常 String item = (String) listOfRawTypes.get(0); //需要顯式的類型轉(zhuǎn)換 item = (String) listOfRawTypes.get(1); //拋ClassCastException，因?yàn)镮nteger不能被轉(zhuǎn)換為String List<String> listOfString = new ArrayList(); listOfString.add("abcd"); listOfString.add(1234); //編譯錯(cuò)誤，比在運(yùn)行時(shí)拋異常要好 item = listOfString.get(0); //不需要顯式的類型轉(zhuǎn)換 - 編譯器自動(dòng)轉(zhuǎn)換
Java 語(yǔ)言中引入泛型是一個(gè)較大的功能增強(qiáng)。不僅語(yǔ)言、類型系統(tǒng)和編譯器有了較大的變化，以支持泛型，而且類庫(kù)也進(jìn)行了大翻修，所以許多重要的類，比如集合框架，都已經(jīng)成為泛型化的了。
這帶來(lái)了很多好處：
1，類型安全。 泛型的主要目標(biāo)是提高 Java 程序的類型安全。通過(guò)知道使用泛型定義的變量的類型限制，編譯器可以在一個(gè)高得多的程度上驗(yàn)證類型假設(shè)。沒(méi)有泛型，這些假設(shè)就只存在于程序員的頭腦中（或者如果幸運(yùn)的話，還存在于代碼注釋中）。
2，消除強(qiáng)制類型轉(zhuǎn)換。 泛型的一個(gè)附帶好處是，消除源代碼中的許多強(qiáng)制類型轉(zhuǎn)換。這使得代碼更加可讀，并且減少了出錯(cuò)機(jī)會(huì)。
3，潛在的性能收益。 泛型為較大的優(yōu)化帶來(lái)可能。在泛型的初始實(shí)現(xiàn)中，編譯器將強(qiáng)制類型轉(zhuǎn)換（沒(méi)有泛型的話，程序員會(huì)指定這些強(qiáng)制類型轉(zhuǎn)換）插入生成的字節(jié)碼中。但是更多類型信息可用于編譯器這一事實(shí)，為未來(lái)版本的 JVM 的優(yōu)化帶來(lái)可能。由于泛型的實(shí)現(xiàn)方式，支持泛型（幾乎）不需要 JVM 或類文件更改。所有工作都在編譯器中完成，編譯器生成類似于沒(méi)有泛型（和強(qiáng)制類型轉(zhuǎn)換）時(shí)所寫(xiě)的代碼，只是更能確保類型安全而已。
Java語(yǔ)言引入泛型的好處是安全簡(jiǎn)單。泛型的好處是在編譯的時(shí)候檢查類型安全，并且所有的強(qiáng)制轉(zhuǎn)換都是自動(dòng)和隱式的，提高代碼的重用率。
泛型在使用中還有一些規(guī)則和限制：
1、泛型的類型參數(shù)只能是類類型（包括自定義類），不能是簡(jiǎn)單類型。
2、同一種泛型可以對(duì)應(yīng)多個(gè)版本（因?yàn)閰?shù)類型是不確定的），不同版本的泛型類實(shí)例是不兼容的。
3、泛型的類型參數(shù)可以有多個(gè)。
4、泛型的參數(shù)類型可以使用extends語(yǔ)句，例如<T extends superclass>。習(xí)慣上成為“有界類型”。
5、泛型的參數(shù)類型還可以是通配符類型。例如Class<?> classType = Class.forName(Java.lang.String);
重寫(xiě)方法的規(guī)則：
1、參數(shù)列表必須完全與被重寫(xiě)的方法相同，否則不能稱其為重寫(xiě)而是重載。
2、返回的類型必須一直與被重寫(xiě)的方法的返回類型相同，否則不能稱其為重寫(xiě)而是重載。
3、訪問(wèn)修飾符的限制一定要大于被重寫(xiě)方法的訪問(wèn)修飾符（public>protected>default>private）
4、重寫(xiě)方法一定不能拋出新的檢查異常或者比被重寫(xiě)方法申明更加寬泛的檢查型異常。例如：
父類的一個(gè)方法申明了一個(gè)檢查異常IOException，在重寫(xiě)這個(gè)方法是就不能拋出Exception,只能拋出IOException的子類異常，可以拋出非檢查異常。
而重載的規(guī)則：
1、必須具有不同的參數(shù)列表；
2、可以有不責(zé)罵的返回類型，只要參數(shù)列表不同就可以了；
3、可以有不同的訪問(wèn)修飾符；
4、可以拋出不同的異常；
重寫(xiě)與重載的區(qū)別在于：
重寫(xiě)多態(tài)性起作用，對(duì)調(diào)用被重載過(guò)的方法可以大大減少代碼的輸入量，同一個(gè)方法名只要往里面?zhèn)鬟f不同的參數(shù)就可以擁有不同的功能或返回值。
用好重寫(xiě)和重載可以設(shè)計(jì)一個(gè)結(jié)構(gòu)清晰而簡(jiǎn)潔的類，可以說(shuō)重寫(xiě)和重載在編寫(xiě)代碼過(guò)程中的作用非同一般.
擦除法并不代表編譯后的字節(jié)碼中就不包含我們?cè)谠创a定義的泛型類型了。而是在字節(jié)碼中引入新屬性Signature 和 LocalVariableTypeTable 來(lái)存儲(chǔ)泛型。這也是為什么可以通過(guò)返回值重載，及通過(guò)反射獲取到泛型的根本原因
Collections.synchronizedMap是個(gè)比較老的API了，實(shí)際用起來(lái)還要手工做一些事。建議樓主用Java5的ConcurrentHashMap或Java6的ConcurrentSkipListMap
1、首先要清楚源碼的編碼方式是什么？如果源碼的編碼是utf-8 就需要這樣修改Preferences General > Workspace 修改Text file encoding為UTF-8后才行。重新啟動(dòng)Eclipse就可以解決了()
向ThreadLocal里面存東西就是向它里面的Map存東西的，然后ThreadLocal把這個(gè)Map掛到當(dāng)前的線程底下，這樣Map就只屬于這個(gè)線程了。
1.打開(kāi)旺旺的聊天窗口
2.command+shift+n 會(huì)彈出登錄匡
是因?yàn)樽髠?cè)的視圖是Project Explorer而不是Package Explorer，直接在菜單欄上面找到“Window”-“Show view...”-“Other”，搜索“package”找到Package Explorer，并且讓它顯示出來(lái)，就OK了，在Package Explorer里面是有Referenced Libraries的。
摘要: 什么是HTTP協(xié)議協(xié)議是指計(jì)算機(jī)通信網(wǎng)絡(luò)中兩臺(tái)計(jì)算機(jī)之間進(jìn)行通信所必須共同遵守的規(guī)定或規(guī)則，超文本傳輸協(xié)議(HTTP)是一種通信協(xié)議，它允許將超文本標(biāo)記語(yǔ)言(HTML)文檔從Web服務(wù)器傳送到客戶端的瀏覽器 目前我們使用的是HTTP/1.1 版本W(wǎng)eb服務(wù)器，瀏覽器,代理服務(wù)器當(dāng)我們打開(kāi)瀏覽器，在地址欄中輸入U(xiǎn)RL，然后我們就看到了網(wǎng)頁(yè)。 原理是怎樣的呢？實(shí)際上我們輸入U(xiǎn)RL后，我們的瀏...
閱讀全文
基于 HTTP 長(zhǎng)連接的“服務(wù)器推”技術(shù)
Comet 簡(jiǎn)介
瀏覽器作為 Web 應(yīng)用的前臺(tái)，自身的處理功能比較有限。瀏覽器的發(fā)展需要客戶端升級(jí)軟件，同時(shí)由于客戶端瀏覽器軟件的多樣性，在某種意義上，也影響了瀏覽器新技術(shù)的推廣。在 Web 應(yīng)用中，瀏覽器的主要工作是發(fā)送請(qǐng)求、解析服務(wù)器返回的信息以不同的風(fēng)格顯示。AJAX 是瀏覽器技術(shù)發(fā)展的成果，通過(guò)在瀏覽器端發(fā)送異步請(qǐng)求，提高了單用戶操作的響應(yīng)性。但 Web 本質(zhì)上是一個(gè)多用戶的系統(tǒng)，對(duì)任何用戶來(lái)說(shuō)，可以認(rèn)為服務(wù)器是另外一個(gè)用戶。現(xiàn)有 AJAX 技術(shù)的發(fā)展并不能解決在一個(gè)多用戶的 Web 應(yīng)用中，將更新的信息實(shí)時(shí)傳送給客戶端，從而用戶可能在“過(guò)時(shí)”的信息下進(jìn)行操作。而 AJAX 的應(yīng)用又使后臺(tái)數(shù)據(jù)更新更加頻繁成為可能。
圖 1. 傳統(tǒng)的 Web 應(yīng)用模型與基于 AJAX 的模型之比較
“服務(wù)器推”是一種很早就存在的技術(shù)，以前在實(shí)現(xiàn)上主要是通過(guò)客戶端的套接口，或是服務(wù)器端的遠(yuǎn)程調(diào)用。因?yàn)闉g覽器技術(shù)的發(fā)展比較緩慢，沒(méi)有為“服務(wù)器推”的實(shí)現(xiàn)提供很好的支持，在純?yōu)g覽器的應(yīng)用中很難有一個(gè)完善的方案去實(shí)現(xiàn)“服務(wù)器推”并用于商業(yè)程序。最近幾年，因?yàn)?AJAX 技術(shù)的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 組件中可以解決 IE 的加載顯示問(wèn)題，一些受歡迎的應(yīng)用如 meebo，gmail+gtalk 在實(shí)現(xiàn)中使用了這些新技術(shù)；同時(shí)“服務(wù)器推”在現(xiàn)實(shí)應(yīng)用中確實(shí)存在很多需求。因?yàn)檫@些原因，基于純?yōu)g覽器的“服務(wù)器推”技術(shù)開(kāi)始受到較多關(guān)注，Alex Russell（Dojo Toolkit 的項(xiàng)目 Lead）稱這種基于 HTTP 長(zhǎng)連接、無(wú)須在瀏覽器端安裝插件的“服務(wù)器推”技術(shù)為“Comet”。目前已經(jīng)出現(xiàn)了一些成熟的 Comet 應(yīng)用以及各種開(kāi)源框架；一些 Web 服務(wù)器如 Jetty 也在為支持大量并發(fā)的長(zhǎng)連接進(jìn)行了很多改進(jìn)。關(guān)于 Comet 技術(shù)最新的發(fā)展?fàn)顩r請(qǐng)參考關(guān)于 Comet 的 wiki。
下面將介紹兩種 Comet 應(yīng)用的實(shí)現(xiàn)模型。
基于 AJAX 的長(zhǎng)輪詢（long-polling）方式
如 圖 1 所示，AJAX 的出現(xiàn)使得 JavaScript 可以調(diào)用 XMLHttpRequest 對(duì)象發(fā)出 HTTP 請(qǐng)求，JavaScript 響應(yīng)處理函數(shù)根據(jù)服務(wù)器返回的信息對(duì) HTML 頁(yè)面的顯示進(jìn)行更新。使用 AJAX 實(shí)現(xiàn)“服務(wù)器推”與傳統(tǒng)的 AJAX 應(yīng)用不同之處在于：
- 服務(wù)器端會(huì)阻塞請(qǐng)求直到有數(shù)據(jù)傳遞或超時(shí)才返回。
- 客戶端 JavaScript 響應(yīng)處理函數(shù)會(huì)在處理完服務(wù)器返回的信息后，再次發(fā)出請(qǐng)求，重新建立連接。
- 當(dāng)客戶端處理接收的數(shù)據(jù)、重新建立連接時(shí)，服務(wù)器端可能有新的數(shù)據(jù)到達(dá)；這些信息會(huì)被服務(wù)器端保存直到客戶端重新建立連接，客戶端會(huì)一次把當(dāng)前服務(wù)器端所有的信息取回。
圖 2. 基于長(zhǎng)輪詢的服務(wù)器推模型
一些應(yīng)用及示例如 “Meebo”, “Pushlet Chat” 都采用了這種長(zhǎng)輪詢的方式。相對(duì)于“輪詢”（poll），這種長(zhǎng)輪詢方式也可以稱為“拉”（pull）。因?yàn)檫@種方案基于 AJAX，具有以下一些優(yōu)點(diǎn)：請(qǐng)求異步發(fā)出；無(wú)須安裝插件；IE、Mozilla FireFox 都支持 AJAX。
在這種長(zhǎng)輪詢方式下，客戶端是在 XMLHttpRequest 的 readystate 為 4（即數(shù)據(jù)傳輸結(jié)束）時(shí)調(diào)用回調(diào)函數(shù)，進(jìn)行信息處理。當(dāng) readystate 為 4 時(shí)，數(shù)據(jù)傳輸結(jié)束，連接已經(jīng)關(guān)閉。Mozilla Firefox 提供了對(duì) Streaming AJAX 的支持， 即 readystate 為 3 時(shí)（數(shù)據(jù)仍在傳輸中），客戶端可以讀取數(shù)據(jù)，從而無(wú)須關(guān)閉連接，就能讀取處理服務(wù)器端返回的信息。IE 在 readystate 為 3 時(shí)，不能讀取服務(wù)器返回的數(shù)據(jù)，目前 IE 不支持基于 Streaming AJAX。
基于 Iframe 及 htmlfile 的流（streaming）方式
iframe 是很早就存在的一種 HTML 標(biāo)記， 通過(guò)在 HTML 頁(yè)面里嵌入一個(gè)隱蔵幀，然后將這個(gè)隱蔵幀的 SRC 屬性設(shè)為對(duì)一個(gè)長(zhǎng)連接的請(qǐng)求，服務(wù)器端就能源源不斷地往客戶端輸入數(shù)據(jù)。
圖 3. 基于流方式的服務(wù)器推模型
上節(jié)提到的 AJAX 方案是在 JavaScript 里處理 XMLHttpRequest 從服務(wù)器取回的數(shù)據(jù)，然后 Javascript 可以很方便的去控制 HTML 頁(yè)面的顯示。同樣的思路用在 iframe 方案的客戶端，iframe 服務(wù)器端并不返回直接顯示在頁(yè)面的數(shù)據(jù)，而是返回對(duì)客戶端 Javascript 函數(shù)的調(diào)用，如“<script type="text/javascript">js_func(“data from server ”)</script>”。服務(wù)器端將返回的數(shù)據(jù)作為客戶端 JavaScript 函數(shù)的參數(shù)傳遞；客戶端瀏覽器的 Javascript 引擎在收到服務(wù)器返回的 JavaScript 調(diào)用時(shí)就會(huì)去執(zhí)行代碼。
從 圖 3 可以看到，每次數(shù)據(jù)傳送不會(huì)關(guān)閉連接，連接只會(huì)在通信出現(xiàn)錯(cuò)誤時(shí)，或是連接重建時(shí)關(guān)閉（一些防火墻常被設(shè)置為丟棄過(guò)長(zhǎng)的連接， 服務(wù)器端可以設(shè)置一個(gè)超時(shí)時(shí)間， 超時(shí)后通知客戶端重新建立連接，并關(guān)閉原來(lái)的連接）。
使用 iframe 請(qǐng)求一個(gè)長(zhǎng)連接有一個(gè)很明顯的不足之處：IE、Morzilla Firefox 下端的進(jìn)度欄都會(huì)顯示加載沒(méi)有完成，而且 IE 上方的圖標(biāo)會(huì)不停的轉(zhuǎn)動(dòng)，表示加載正在進(jìn)行。Google 的天才們使用一個(gè)稱為“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問(wèn)題，并將這種方法用到了 gmail+gtalk 產(chǎn)品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介紹了這種方法。Zeitoun 網(wǎng)站提供的 comet-iframe.tar.gz，封裝了一個(gè)基于 iframe 和 htmlfile 的 JavaScript comet 對(duì)象，支持 IE、Mozilla Firefox 瀏覽器，可以作為參考。（請(qǐng)參見(jiàn) 參考資源）
回頁(yè)首
使用 Comet 模型開(kāi)發(fā)自己的應(yīng)用
上面介紹了兩種基于 HTTP 長(zhǎng)連接的“服務(wù)器推”架構(gòu)，更多描述了客戶端處理長(zhǎng)連接的技術(shù)。對(duì)于一個(gè)實(shí)際的應(yīng)用而言，系統(tǒng)的穩(wěn)定性和性能是非常重要的。將 HTTP 長(zhǎng)連接用于實(shí)際應(yīng)用，很多細(xì)節(jié)需要考慮。
不要在同一客戶端同時(shí)使用超過(guò)兩個(gè)的 HTTP 長(zhǎng)連接
我們使用 IE 下載文件時(shí)會(huì)有這樣的體驗(yàn)，從同一個(gè) Web 服務(wù)器下載文件，最多只能有兩個(gè)文件同時(shí)被下載。第三個(gè)文件的下載會(huì)被阻塞，直到前面下載的文件下載完畢。這是因?yàn)?HTTP 1.1 規(guī)范中規(guī)定，客戶端不應(yīng)該與服務(wù)器端建立超過(guò)兩個(gè)的 HTTP 連接， 新的連接會(huì)被阻塞。而 IE 在實(shí)現(xiàn)中嚴(yán)格遵守了這種規(guī)定。
HTTP 1.1 對(duì)兩個(gè)長(zhǎng)連接的限制，會(huì)對(duì)使用了長(zhǎng)連接的 Web 應(yīng)用帶來(lái)如下現(xiàn)象：在客戶端如果打開(kāi)超過(guò)兩個(gè)的 IE 窗口去訪問(wèn)同一個(gè)使用了長(zhǎng)連接的 Web 服務(wù)器，第三個(gè) IE 窗口的 HTTP 請(qǐng)求被前兩個(gè)窗口的長(zhǎng)連接阻塞。
所以在開(kāi)發(fā)長(zhǎng)連接的應(yīng)用時(shí)， 必須注意在使用了多個(gè) frame 的頁(yè)面中，不要為每個(gè) frame 的頁(yè)面都建立一個(gè) HTTP 長(zhǎng)連接，這樣會(huì)阻塞其它的 HTTP 請(qǐng)求，在設(shè)計(jì)上考慮讓多個(gè) frame 的更新共用一個(gè)長(zhǎng)連接。
服務(wù)器端的性能和可擴(kuò)展性
一般 Web 服務(wù)器會(huì)為每個(gè)連接創(chuàng)建一個(gè)線程，如果在大型的商業(yè)應(yīng)用中使用 Comet，服務(wù)器端需要維護(hù)大量并發(fā)的長(zhǎng)連接。在這種應(yīng)用背景下，服務(wù)器端需要考慮負(fù)載均衡和集群技術(shù)；或是在服務(wù)器端為長(zhǎng)連接作一些改進(jìn)。
應(yīng)用和技術(shù)的發(fā)展總是帶來(lái)新的需求，從而推動(dòng)新技術(shù)的發(fā)展。HTTP 1.1 與 1.0 規(guī)范有一個(gè)很大的不同：1.0 規(guī)范下服務(wù)器在處理完每個(gè) Get/Post 請(qǐng)求后會(huì)關(guān)閉套接口連接； 而 1.1 規(guī)范下服務(wù)器會(huì)保持這個(gè)連接，在處理兩個(gè)請(qǐng)求的間隔時(shí)間里，這個(gè)連接處于空閑狀態(tài)。 Java 1.4 引入了支持異步 IO 的 java.nio 包。當(dāng)連接處于空閑時(shí)，為這個(gè)連接分配的線程資源會(huì)返還到線程池，可以供新的連接使用；當(dāng)原來(lái)處于空閑的連接的客戶發(fā)出新的請(qǐng)求，會(huì)從線程池里分配一個(gè)線程資源處理這個(gè)請(qǐng)求。 這種技術(shù)在連接處于空閑的機(jī)率較高、并發(fā)連接數(shù)目很多的場(chǎng)景下對(duì)于降低服務(wù)器的資源負(fù)載非常有效。
但是 AJAX 的應(yīng)用使請(qǐng)求的出現(xiàn)變得頻繁，而 Comet 則會(huì)長(zhǎng)時(shí)間占用一個(gè)連接，上述的服務(wù)器模型在新的應(yīng)用背景下會(huì)變得非常低效，線程池里有限的線程數(shù)甚至可能會(huì)阻塞新的連接。Jetty 6 Web 服務(wù)器針對(duì) AJAX、Comet 應(yīng)用的特點(diǎn)進(jìn)行了很多創(chuàng)新的改進(jìn)，請(qǐng)參考文章“AJAX，Comet and Jetty”（請(qǐng)參見(jiàn) 參考資源）。
控制信息與數(shù)據(jù)信息使用不同的 HTTP 連接
使用長(zhǎng)連接時(shí)，存在一個(gè)很常見(jiàn)的場(chǎng)景：客戶端網(wǎng)頁(yè)需要關(guān)閉，而服務(wù)器端還處在讀取數(shù)據(jù)的堵塞狀態(tài)，客戶端需要及時(shí)通知服務(wù)器端關(guān)閉數(shù)據(jù)連接。服務(wù)器在收到關(guān)閉請(qǐng)求后首先要從讀取數(shù)據(jù)的阻塞狀態(tài)喚醒，然后釋放為這個(gè)客戶端分配的資源，再關(guān)閉連接。
所以在設(shè)計(jì)上，我們需要使客戶端的控制請(qǐng)求和數(shù)據(jù)請(qǐng)求使用不同的 HTTP 連接，才能使控制請(qǐng)求不會(huì)被阻塞。
在實(shí)現(xiàn)上，如果是基于 iframe 流方式的長(zhǎng)連接，客戶端頁(yè)面需要使用兩個(gè) iframe，一個(gè)是控制幀，用于往服務(wù)器端發(fā)送控制請(qǐng)求，控制請(qǐng)求能很快收到響應(yīng)，不會(huì)被堵塞；一個(gè)是顯示幀，用于往服務(wù)器端發(fā)送長(zhǎng)連接請(qǐng)求。如果是基于 AJAX 的長(zhǎng)輪詢方式，客戶端可以異步地發(fā)出一個(gè) XMLHttpRequest 請(qǐng)求，通知服務(wù)器端關(guān)閉數(shù)據(jù)連接。
在客戶和服務(wù)器之間保持“心跳”信息
在瀏覽器與服務(wù)器之間維持一個(gè)長(zhǎng)連接會(huì)為通信帶來(lái)一些不確定性：因?yàn)閿?shù)據(jù)傳輸是隨機(jī)的，客戶端不知道何時(shí)服務(wù)器才有數(shù)據(jù)傳送。服務(wù)器端需要確保當(dāng)客戶端不再工作時(shí)，釋放為這個(gè)客戶端分配的資源，防止內(nèi)存泄漏。因此需要一種機(jī)制使雙方知道大家都在正常運(yùn)行。在實(shí)現(xiàn)上：
- 服務(wù)器端在阻塞讀時(shí)會(huì)設(shè)置一個(gè)時(shí)限，超時(shí)后阻塞讀調(diào)用會(huì)返回，同時(shí)發(fā)給客戶端沒(méi)有新數(shù)據(jù)到達(dá)的心跳信息。此時(shí)如果客戶端已經(jīng)關(guān)閉，服務(wù)器往通道寫(xiě)數(shù)據(jù)會(huì)出現(xiàn)異常，服務(wù)器端就會(huì)及時(shí)釋放為這個(gè)客戶端分配的資源。
- 如果客戶端使用的是基于 AJAX 的長(zhǎng)輪詢方式；服務(wù)器端返回?cái)?shù)據(jù)、關(guān)閉連接后，經(jīng)過(guò)某個(gè)時(shí)限沒(méi)有收到客戶端的再次請(qǐng)求，會(huì)認(rèn)為客戶端不能正常工作，會(huì)釋放為這個(gè)客戶端分配、維護(hù)的資源。
- 當(dāng)服務(wù)器處理信息出現(xiàn)異常情況，需要發(fā)送錯(cuò)誤信息通知客戶端，同時(shí)釋放資源、關(guān)閉連接。
Pushlet - 開(kāi)源 Comet 框架
Pushlet 是一個(gè)開(kāi)源的 Comet 框架，在設(shè)計(jì)上有很多值得借鑒的地方，對(duì)于開(kāi)發(fā)輕量級(jí)的 Comet 應(yīng)用很有參考價(jià)值。
觀察者模型
Pushlet 使用了觀察者模型：客戶端發(fā)送請(qǐng)求，訂閱感興趣的事件；服務(wù)器端為每個(gè)客戶端分配一個(gè)會(huì)話 ID 作為標(biāo)記，事件源會(huì)把新產(chǎn)生的事件以多播的方式發(fā)送到訂閱者的事件隊(duì)列里。
客戶端 JavaScript 庫(kù)
pushlet 提供了基于 AJAX 的 JavaScript 庫(kù)文件用于實(shí)現(xiàn)長(zhǎng)輪詢方式的“服務(wù)器推”；還提供了基于 iframe 的 JavaScript 庫(kù)文件用于實(shí)現(xiàn)流方式的“服務(wù)器推”。
JavaScript 庫(kù)做了很多封裝工作：
- 定義客戶端的通信狀態(tài)：
STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING； - 保存服務(wù)器分配的會(huì)話 ID，在建立連接之后的每次請(qǐng)求中會(huì)附上會(huì)話 ID 表明身份；
- 提供了
join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供頁(yè)面調(diào)用； - 提供了處理響應(yīng)的 JavaScript 函數(shù)接口
onData()、onEvent()…
網(wǎng)頁(yè)可以很方便地使用這兩個(gè) JavaScript 庫(kù)文件封裝的 API 與服務(wù)器進(jìn)行通信。
客戶端與服務(wù)器端通信信息格式
pushlet 定義了一套客戶與服務(wù)器通信的信息格式，使用 XML 格式。定義了客戶端發(fā)送請(qǐng)求的類型：join、leave、subscribe、unsubscribe、listen、refresh；以及響應(yīng)的事件類型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。
服務(wù)器端事件隊(duì)列管理
pushlet 在服務(wù)器端使用 Java Servlet 實(shí)現(xiàn)，其數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)框架仍可適用于 PHP、C 編寫(xiě)的后臺(tái)客戶端。
Pushlet 支持客戶端自己選擇使用流、拉（長(zhǎng)輪詢）、輪詢方式。服務(wù)器端根據(jù)客戶選擇的方式在讀取事件隊(duì)列（fetchEvents）時(shí)進(jìn)行不同的處理。“輪詢”模式下 fetchEvents() 會(huì)馬上返回。”流“和”拉“模式使用阻塞的方式讀事件，如果超時(shí)，會(huì)發(fā)給客戶端發(fā)送一個(gè)沒(méi)有新信息收到的“heartbeat“事件，如果是“拉”模式，會(huì)把“heartbeat”與“refresh”事件一起傳給客戶端，通知客戶端重新發(fā)出請(qǐng)求、建立連接。
客戶服務(wù)器之間的會(huì)話管理
服務(wù)端在客戶端發(fā)送 join 請(qǐng)求時(shí)，會(huì)為客戶端分配一個(gè)會(huì)話 ID， 并傳給客戶端，然后客戶端就通過(guò)此會(huì)話 ID 標(biāo)明身份發(fā)出subscribe 和 listen 請(qǐng)求。服務(wù)器端會(huì)為每個(gè)會(huì)話維護(hù)一個(gè)訂閱的主題集合、事件隊(duì)列。
服務(wù)器端的事件源會(huì)把新產(chǎn)生的事件以多播的方式發(fā)送到每個(gè)會(huì)話（即訂閱者）的事件隊(duì)列里。
回頁(yè)首
小結(jié)
本文介紹了如何在現(xiàn)有的技術(shù)基礎(chǔ)上選擇合適的方案開(kāi)發(fā)一個(gè)“服務(wù)器推”的應(yīng)用，最優(yōu)的方案還是取決于應(yīng)用需求的本身。相對(duì)于傳統(tǒng)的 Web 應(yīng)用， 目前開(kāi)發(fā) Comet 應(yīng)用還是具有一定的挑戰(zhàn)性。
“服務(wù)器推”存在廣泛的應(yīng)用需求，為了使 Comet 模型適用于大規(guī)模的商業(yè)應(yīng)用，以及方便用戶構(gòu)建 Comet 應(yīng)用，最近幾年，無(wú)論是服務(wù)器還是瀏覽器都出現(xiàn)了很多新技術(shù)，同時(shí)也出現(xiàn)了很多開(kāi)源的 Comet 框架、協(xié)議。需求推動(dòng)技術(shù)的發(fā)展，相信 Comet 的應(yīng)用會(huì)變得和 AJAX 一樣普及。
vTCP連接的建立
v
第一次握手：客戶端TCP首先給服務(wù)器端TCP發(fā)送一個(gè)特殊的TCP數(shù)據(jù)
段。該數(shù)據(jù)段不包含應(yīng)用層數(shù)據(jù)，并將頭部中的SYN位設(shè)置為1，所以該數(shù)
據(jù)段被稱為SYN數(shù)據(jù)段。另外，客戶選擇一個(gè)初始序列號(hào)SEQ，設(shè)SEQ＝x
并將這個(gè)編號(hào)放到初始的TCP SYN數(shù)據(jù)段的序列號(hào)字段中。該數(shù)據(jù)段被封
裝到一個(gè)IP數(shù)據(jù)報(bào)中，并發(fā)送給服務(wù)器。
第二次握手：一旦裝有TCP SYN數(shù)據(jù)段的IP數(shù)據(jù)報(bào)到達(dá)了服務(wù)器主機(jī)，服
務(wù)器將從該數(shù)據(jù)報(bào)中提取出TCP SYN數(shù)據(jù)段，給該連接分配TCP緩沖區(qū)和
變量，并給客戶TCP發(fā)送一個(gè)允許連接的數(shù)據(jù)段。這個(gè)允許連接的數(shù)據(jù)段
也不包含任何應(yīng)用層數(shù)據(jù)。但是，它的頭部中裝載著3個(gè)重要信息。首先，
SYN被設(shè)置為1；其次，TCP數(shù)據(jù)段頭部的確認(rèn)字段被設(shè)置為x＋1；最后，
服務(wù)器選擇自己的初始順序號(hào)，SEQ=y，并將該值放到TCP數(shù)據(jù)段頭部的
序列號(hào)字段中。
第三次握手：在接收到允許連接數(shù)據(jù)段之后，客戶也會(huì)給連接分配緩沖區(qū)
和變量。客戶端主機(jī)還會(huì)給服務(wù)器發(fā)送另一個(gè)數(shù)據(jù)段，對(duì)服務(wù)器的允許連
接數(shù)據(jù)段給出確認(rèn)。議中連接過(guò)程.png)
報(bào)錯(cuò)：springmvc threw exception com.ibatis.sqlmap.client.SqlMapException: There is
no statement named 語(yǔ)句名 in this SqlMap.sqlmap-config.xml 中 必須加上這行：<settings cacheModelsEnabled="true" enhancementEnabled="false" lazyLoadingEnabled="false" maxRequests="3000" maxSessions="3000" maxTransactions="3000" useStatementNamespaces="true"/>
讓root用戶可以遠(yuǎn)程登錄
--------------------------------------------------------------------------------
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'mypassword' WITH GRANT OPTION;