2011年7月5日
http://www.oracle.com/technetwork/java/archive-139210.html
javap -g Foo.java (-g 生成行號)
javap -c -s -l -verbose Foo
裝箱：從基本類型轉換成Object類型，稱之為裝箱；***拆箱：從Object轉換乘基本類型的操作，稱之為拆箱。 這個操作在反射過程中用的比較的多。 裝箱：在堆中建立一個Object實例，把你指定的值復制成去；***拆箱：判別引用指向的堆中信息是否是要拆成的類型，是取出堆中值送給棧中變量，否則報異常
//在-128~127 之外的數 Integer num1 = 297; Integer num2 = 297; System.out.println("num1==num2: "+(num1==num2)); // 在-128~127 之內的數 Integer num3 = 97; Integer num4 = 97; System.out.println("num3==num4: "+(num3==num4)); 打印的結果是：num1==num2: false num3==num4: true
很奇怪吧：這就歸結于java對于Integer與int的自動裝箱與拆箱的設計，是一種模式：叫享元模式（flyweight） 為了加大對簡單數字的重利用，java定義：在自動裝箱時對于值從–128到127之間的值，它們被裝箱為Integer對象后，會存在內存中被重用，始終只存在一個對象 而如果超過了從–128到127之間的值，被裝箱后的Integer對象并不會被重用，即相當于每次裝箱時都新建一個 Integer對象；明白了吧 以上的現象是由于使用了自動裝箱所引起的，如果你沒有使用自動裝箱，而是跟一般類一樣，用new來進行實例化，就會每次new就都一個新的對象；
1. Java中的泛型是什么 ? 使用泛型的好處是什么?
這是在各種Java泛型面試中，一開場你就會被問到的問題中的一個，主要集中在初級和中級面試中。那些擁有Java1.4或更早版本的開發背景的人都知道，在集合中存儲對象并在使用前進行類型轉換是多么的不方便。泛型防止了那種情況的發生。它提供了編譯期的類型安全，確保你只能把正確類型的對象放入集合中，避免了在運行時出現ClassCastException。
2. Java的泛型是如何工作的 ? 什么是類型擦除 ?
這是一道更好的泛型面試題。泛型是通過類型擦除來實現的，編譯器在編譯時擦除了所有類型相關的信息，所以在運行時不存在任何類型相關的信息。例如List<String>在運行時僅用一個List來表示。這樣做的目的，是確保能和Java 5之前的版本開發二進制類庫進行兼容。你無法在運行時訪問到類型參數，因為編譯器已經把泛型類型轉換成了原始類型。根據你對這個泛型問題的回答情況，你會得到一些后續提問，比如為什么泛型是由類型擦除來實現的或者給你展示一些會導致編譯器出錯的錯誤泛型代碼。請閱讀我的Java中泛型是如何工作的來了解更多信息。
3. 什么是泛型中的限定通配符和非限定通配符 ?
這是另一個非常流行的Java泛型面試題。限定通配符對類型進行了限制。有兩種限定通配符，一種是<? extends T>它通過確保類型必須是T的子類來設定類型的上界，另一種是<? super T>它通過確保類型必須是T的父類來設定類型的下界。泛型類型必須用限定內的類型來進行初始化，否則會導致編譯錯誤。另一方面<?>表示了非限定通配符，因為<?>可以用任意類型來替代。更多信息請參閱我的文章泛型中限定通配符和非限定通配符之間的區別。
4. List<? extends T>和List <? super T>之間有什么區別 ?
這和上一個面試題有聯系，有時面試官會用這個問題來評估你對泛型的理解，而不是直接問你什么是限定通配符和非限定通配符。這兩個List的聲明都是限定通配符的例子，List<? extends T>可以接受任何繼承自T的類型的List，而List<? super T>可以接受任何T的父類構成的List。例如List<? extends Number>可以接受List<Integer>或List<Float>。在本段出現的連接中可以找到更多信息。
5. 如何編寫一個泛型方法，讓它能接受泛型參數并返回泛型類型?
編寫泛型方法并不困難，你需要用泛型類型來替代原始類型，比如使用T, E or K,V等被廣泛認可的類型占位符。泛型方法的例子請參閱Java集合類框架。最簡單的情況下，一個泛型方法可能會像這樣:
public V put(K key, V value) { return cache.put(key, value); } 6. Java中如何使用泛型編寫帶有參數的類?
這是上一道面試題的延伸。面試官可能會要求你用泛型編寫一個類型安全的類，而不是編寫一個泛型方法。關鍵仍然是使用泛型類型來代替原始類型，而且要使用JDK中采用的標準占位符。
7. 編寫一段泛型程序來實現LRU緩存?
對于喜歡Java編程的人來說這相當于是一次練習。給你個提示，LinkedHashMap可以用來實現固定大小的LRU緩存，當LRU緩存已經滿了的時候，它會把最老的鍵值對移出緩存。LinkedHashMap提供了一個稱為removeEldestEntry()的方法，該方法會被put()和putAll()調用來刪除最老的鍵值對。當然，如果你已經編寫了一個可運行的JUnit測試，你也可以隨意編寫你自己的實現代碼。
8. 你可以把List<String>傳遞給一個接受List<Object>參數的方法嗎？
對任何一個不太熟悉泛型的人來說，這個Java泛型題目看起來令人疑惑，因為乍看起來String是一種Object，所以List<String>應當可以用在需要List<Object>的地方，但是事實并非如此。真這樣做的話會導致編譯錯誤。如果你再深一步考慮，你會發現Java這樣做是有意義的，因為List<Object>可以存儲任何類型的對象包括String, Integer等等，而List<String>卻只能用來存儲Strings。
List<Object> objectList; List<String> stringList; objectList = stringList; //compilation error incompatible types
9. Array中可以用泛型嗎?
這可能是Java泛型面試題中最簡單的一個了，當然前提是你要知道Array事實上并不支持泛型，這也是為什么Joshua Bloch在Effective Java一書中建議使用List來代替Array，因為List可以提供編譯期的類型安全保證，而Array卻不能。
10. 如何阻止Java中的類型未檢查的警告?
如果你把泛型和原始類型混合起來使用，例如下列代碼，Java 5的javac編譯器會產生類型未檢查的警告，例如
List<String> rawList = new ArrayList() 注意: Hello.java使用了未檢查或稱為不安全的操作;
這種警告可以使用@SuppressWarnings("unchecked")注解來屏蔽。
Java泛型面試題補充更新:
我手頭又拿到了幾個Java泛型面試題跟大家分享下，這幾道題集中在泛型類型和原始類型的區別上，以及我們是否可以用Object來代替限定通配符的使用等等：
Java中List<Object>和原始類型List之間的區別?
原始類型和帶參數類型<Object>之間的主要區別是，在編譯時編譯器不會對原始類型進行類型安全檢查，卻會對帶參數的類型進行檢查，通過使用Object作為類型，可以告知編譯器該方法可以接受任何類型的對象，比如String或Integer。這道題的考察點在于對泛型中原始類型的正確理解。它們之間的第二點區別是，你可以把任何帶參數的類型傳遞給原始類型List，但卻不能把List<String>傳遞給接受List<Object>的方法，因為會產生變異錯誤。更多詳細信息請參閱Java中的泛型是如何工作的。
Java中List<?>和List<Object>之間的區別是什么?
這道題跟上一道題看起來很像，實質上卻完全不同。List<?> 是一個未知類型的List，而List<Object>其實是任意類型的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
想了解更多關于通配符的信息請查看Java中的泛型通配符示例
List<String>和原始類型List之間的區別.
該題類似于“原始類型和帶參數類型之間有什么區別”。帶參數類型是類型安全的，而且其類型安全是由編譯器保證的，但原始類型List卻不是類型安全的。你不能把String之外的任何其它類型的Object存入String類型的List中，而你可以把任何類型的對象存入原始List中。使用泛型的帶參數類型你不需要進行類型轉換，但是對于原始類型，你則需要進行顯式的類型轉換。
List listOfRawTypes = new ArrayList(); listOfRawTypes.add("abc"); listOfRawTypes.add(123); //編譯器允許這樣 - 運行時卻會出現異常 String item = (String) listOfRawTypes.get(0); //需要顯式的類型轉換 item = (String) listOfRawTypes.get(1); //拋ClassCastException，因為Integer不能被轉換為String List<String> listOfString = new ArrayList(); listOfString.add("abcd"); listOfString.add(1234); //編譯錯誤，比在運行時拋異常要好 item = listOfString.get(0); //不需要顯式的類型轉換 - 編譯器自動轉換
Java 語言中引入泛型是一個較大的功能增強。不僅語言、類型系統和編譯器有了較大的變化，以支持泛型，而且類庫也進行了大翻修，所以許多重要的類，比如集合框架，都已經成為泛型化的了。
這帶來了很多好處：
1，類型安全。 泛型的主要目標是提高 Java 程序的類型安全。通過知道使用泛型定義的變量的類型限制，編譯器可以在一個高得多的程度上驗證類型假設。沒有泛型，這些假設就只存在于程序員的頭腦中（或者如果幸運的話，還存在于代碼注釋中）。
2，消除強制類型轉換。 泛型的一個附帶好處是，消除源代碼中的許多強制類型轉換。這使得代碼更加可讀，并且減少了出錯機會。
3，潛在的性能收益。 泛型為較大的優化帶來可能。在泛型的初始實現中，編譯器將強制類型轉換（沒有泛型的話，程序員會指定這些強制類型轉換）插入生成的字節碼中。但是更多類型信息可用于編譯器這一事實，為未來版本的 JVM 的優化帶來可能。由于泛型的實現方式，支持泛型（幾乎）不需要 JVM 或類文件更改。所有工作都在編譯器中完成，編譯器生成類似于沒有泛型（和強制類型轉換）時所寫的代碼，只是更能確保類型安全而已。
Java語言引入泛型的好處是安全簡單。泛型的好處是在編譯的時候檢查類型安全，并且所有的強制轉換都是自動和隱式的，提高代碼的重用率。
泛型在使用中還有一些規則和限制：
1、泛型的類型參數只能是類類型（包括自定義類），不能是簡單類型。
2、同一種泛型可以對應多個版本（因為參數類型是不確定的），不同版本的泛型類實例是不兼容的。
3、泛型的類型參數可以有多個。
4、泛型的參數類型可以使用extends語句，例如<T extends superclass>。習慣上成為“有界類型”。
5、泛型的參數類型還可以是通配符類型。例如Class<?> classType = Class.forName(Java.lang.String);
重寫方法的規則：
1、參數列表必須完全與被重寫的方法相同，否則不能稱其為重寫而是重載。
2、返回的類型必須一直與被重寫的方法的返回類型相同，否則不能稱其為重寫而是重載。
3、訪問修飾符的限制一定要大于被重寫方法的訪問修飾符（public>protected>default>private）
4、重寫方法一定不能拋出新的檢查異常或者比被重寫方法申明更加寬泛的檢查型異常。例如：
父類的一個方法申明了一個檢查異常IOException，在重寫這個方法是就不能拋出Exception,只能拋出IOException的子類異常，可以拋出非檢查異常。
而重載的規則：
1、必須具有不同的參數列表；
2、可以有不責罵的返回類型，只要參數列表不同就可以了；
3、可以有不同的訪問修飾符；
4、可以拋出不同的異常；
重寫與重載的區別在于：
重寫多態性起作用，對調用被重載過的方法可以大大減少代碼的輸入量，同一個方法名只要往里面傳遞不同的參數就可以擁有不同的功能或返回值。
用好重寫和重載可以設計一個結構清晰而簡潔的類，可以說重寫和重載在編寫代碼過程中的作用非同一般.
擦除法并不代表編譯后的字節碼中就不包含我們在源代碼定義的泛型類型了。而是在字節碼中引入新屬性Signature 和 LocalVariableTypeTable 來存儲泛型。這也是為什么可以通過返回值重載，及通過反射獲取到泛型的根本原因
Collections.synchronizedMap是個比較老的API了，實際用起來還要手工做一些事。建議樓主用Java5的ConcurrentHashMap或Java6的ConcurrentSkipListMap
1、首先要清楚源碼的編碼方式是什么？如果源碼的編碼是utf-8 就需要這樣修改Preferences General > Workspace 修改Text file encoding為UTF-8后才行。重新啟動Eclipse就可以解決了()
向ThreadLocal里面存東西就是向它里面的Map存東西的，然后ThreadLocal把這個Map掛到當前的線程底下，這樣Map就只屬于這個線程了。
1.打開旺旺的聊天窗口
2.command+shift+n 會彈出登錄匡
是因為左側的視圖是Project Explorer而不是Package Explorer，直接在菜單欄上面找到“Window”-“Show view...”-“Other”，搜索“package”找到Package Explorer，并且讓它顯示出來，就OK了，在Package Explorer里面是有Referenced Libraries的。
摘要: 什么是HTTP協議協議是指計算機通信網絡中兩臺計算機之間進行通信所必須共同遵守的規定或規則，超文本傳輸協議(HTTP)是一種通信協議，它允許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器 目前我們使用的是HTTP/1.1 版本Web服務器，瀏覽器,代理服務器當我們打開瀏覽器，在地址欄中輸入URL，然后我們就看到了網頁。 原理是怎樣的呢？實際上我們輸入URL后，我們的瀏...
閱讀全文
基于 HTTP 長連接的“服務器推”技術
Comet 簡介
瀏覽器作為 Web 應用的前臺，自身的處理功能比較有限。瀏覽器的發展需要客戶端升級軟件，同時由于客戶端瀏覽器軟件的多樣性，在某種意義上，也影響了瀏覽器新技術的推廣。在 Web 應用中，瀏覽器的主要工作是發送請求、解析服務器返回的信息以不同的風格顯示。AJAX 是瀏覽器技術發展的成果，通過在瀏覽器端發送異步請求，提高了單用戶操作的響應性。但 Web 本質上是一個多用戶的系統，對任何用戶來說，可以認為服務器是另外一個用戶。現有 AJAX 技術的發展并不能解決在一個多用戶的 Web 應用中，將更新的信息實時傳送給客戶端，從而用戶可能在“過時”的信息下進行操作。而 AJAX 的應用又使后臺數據更新更加頻繁成為可能。
圖 1. 傳統的 Web 應用模型與基于 AJAX 的模型之比較
“服務器推”是一種很早就存在的技術，以前在實現上主要是通過客戶端的套接口，或是服務器端的遠程調用。因為瀏覽器技術的發展比較緩慢，沒有為“服務器推”的實現提供很好的支持，在純瀏覽器的應用中很難有一個完善的方案去實現“服務器推”并用于商業程序。最近幾年，因為 AJAX 技術的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 組件中可以解決 IE 的加載顯示問題，一些受歡迎的應用如 meebo，gmail+gtalk 在實現中使用了這些新技術；同時“服務器推”在現實應用中確實存在很多需求。因為這些原因，基于純瀏覽器的“服務器推”技術開始受到較多關注，Alex Russell（Dojo Toolkit 的項目 Lead）稱這種基于 HTTP 長連接、無須在瀏覽器端安裝插件的“服務器推”技術為“Comet”。目前已經出現了一些成熟的 Comet 應用以及各種開源框架；一些 Web 服務器如 Jetty 也在為支持大量并發的長連接進行了很多改進。關于 Comet 技術最新的發展狀況請參考關于 Comet 的 wiki。
下面將介紹兩種 Comet 應用的實現模型。
基于 AJAX 的長輪詢（long-polling）方式
如 圖 1 所示，AJAX 的出現使得 JavaScript 可以調用 XMLHttpRequest 對象發出 HTTP 請求，JavaScript 響應處理函數根據服務器返回的信息對 HTML 頁面的顯示進行更新。使用 AJAX 實現“服務器推”與傳統的 AJAX 應用不同之處在于：
- 服務器端會阻塞請求直到有數據傳遞或超時才返回。
- 客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息后，再次發出請求，重新建立連接。
- 當客戶端處理接收的數據、重新建立連接時，服務器端可能有新的數據到達；這些信息會被服務器端保存直到客戶端重新建立連接，客戶端會一次把當前服務器端所有的信息取回。
圖 2. 基于長輪詢的服務器推模型
一些應用及示例如 “Meebo”, “Pushlet Chat” 都采用了這種長輪詢的方式。相對于“輪詢”（poll），這種長輪詢方式也可以稱為“拉”（pull）。因為這種方案基于 AJAX，具有以下一些優點：請求異步發出；無須安裝插件；IE、Mozilla FireFox 都支持 AJAX。
在這種長輪詢方式下，客戶端是在 XMLHttpRequest 的 readystate 為 4（即數據傳輸結束）時調用回調函數，進行信息處理。當 readystate 為 4 時，數據傳輸結束，連接已經關閉。Mozilla Firefox 提供了對 Streaming AJAX 的支持， 即 readystate 為 3 時（數據仍在傳輸中），客戶端可以讀取數據，從而無須關閉連接，就能讀取處理服務器端返回的信息。IE 在 readystate 為 3 時，不能讀取服務器返回的數據，目前 IE 不支持基于 Streaming AJAX。
基于 Iframe 及 htmlfile 的流（streaming）方式
iframe 是很早就存在的一種 HTML 標記， 通過在 HTML 頁面里嵌入一個隱蔵幀，然后將這個隱蔵幀的 SRC 屬性設為對一個長連接的請求，服務器端就能源源不斷地往客戶端輸入數據。
圖 3. 基于流方式的服務器推模型
上節提到的 AJAX 方案是在 JavaScript 里處理 XMLHttpRequest 從服務器取回的數據，然后 Javascript 可以很方便的去控制 HTML 頁面的顯示。同樣的思路用在 iframe 方案的客戶端，iframe 服務器端并不返回直接顯示在頁面的數據，而是返回對客戶端 Javascript 函數的調用，如“<script type="text/javascript">js_func(“data from server ”)</script>”。服務器端將返回的數據作為客戶端 JavaScript 函數的參數傳遞；客戶端瀏覽器的 Javascript 引擎在收到服務器返回的 JavaScript 調用時就會去執行代碼。
從 圖 3 可以看到，每次數據傳送不會關閉連接，連接只會在通信出現錯誤時，或是連接重建時關閉（一些防火墻常被設置為丟棄過長的連接， 服務器端可以設置一個超時時間， 超時后通知客戶端重新建立連接，并關閉原來的連接）。
使用 iframe 請求一個長連接有一個很明顯的不足之處：IE、Morzilla Firefox 下端的進度欄都會顯示加載沒有完成，而且 IE 上方的圖標會不停的轉動，表示加載正在進行。Google 的天才們使用一個稱為“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問題，并將這種方法用到了 gmail+gtalk 產品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介紹了這種方法。Zeitoun 網站提供的 comet-iframe.tar.gz，封裝了一個基于 iframe 和 htmlfile 的 JavaScript comet 對象，支持 IE、Mozilla Firefox 瀏覽器，可以作為參考。（請參見 參考資源）
回頁首
使用 Comet 模型開發自己的應用
上面介紹了兩種基于 HTTP 長連接的“服務器推”架構，更多描述了客戶端處理長連接的技術。對于一個實際的應用而言，系統的穩定性和性能是非常重要的。將 HTTP 長連接用于實際應用，很多細節需要考慮。
不要在同一客戶端同時使用超過兩個的 HTTP 長連接
我們使用 IE 下載文件時會有這樣的體驗，從同一個 Web 服務器下載文件，最多只能有兩個文件同時被下載。第三個文件的下載會被阻塞，直到前面下載的文件下載完畢。這是因為 HTTP 1.1 規范中規定，客戶端不應該與服務器端建立超過兩個的 HTTP 連接， 新的連接會被阻塞。而 IE 在實現中嚴格遵守了這種規定。
HTTP 1.1 對兩個長連接的限制，會對使用了長連接的 Web 應用帶來如下現象：在客戶端如果打開超過兩個的 IE 窗口去訪問同一個使用了長連接的 Web 服務器，第三個 IE 窗口的 HTTP 請求被前兩個窗口的長連接阻塞。
所以在開發長連接的應用時， 必須注意在使用了多個 frame 的頁面中，不要為每個 frame 的頁面都建立一個 HTTP 長連接，這樣會阻塞其它的 HTTP 請求，在設計上考慮讓多個 frame 的更新共用一個長連接。
服務器端的性能和可擴展性
一般 Web 服務器會為每個連接創建一個線程，如果在大型的商業應用中使用 Comet，服務器端需要維護大量并發的長連接。在這種應用背景下，服務器端需要考慮負載均衡和集群技術；或是在服務器端為長連接作一些改進。
應用和技術的發展總是帶來新的需求，從而推動新技術的發展。HTTP 1.1 與 1.0 規范有一個很大的不同：1.0 規范下服務器在處理完每個 Get/Post 請求后會關閉套接口連接； 而 1.1 規范下服務器會保持這個連接，在處理兩個請求的間隔時間里，這個連接處于空閑狀態。 Java 1.4 引入了支持異步 IO 的 java.nio 包。當連接處于空閑時，為這個連接分配的線程資源會返還到線程池，可以供新的連接使用；當原來處于空閑的連接的客戶發出新的請求，會從線程池里分配一個線程資源處理這個請求。 這種技術在連接處于空閑的機率較高、并發連接數目很多的場景下對于降低服務器的資源負載非常有效。
但是 AJAX 的應用使請求的出現變得頻繁，而 Comet 則會長時間占用一個連接，上述的服務器模型在新的應用背景下會變得非常低效，線程池里有限的線程數甚至可能會阻塞新的連接。Jetty 6 Web 服務器針對 AJAX、Comet 應用的特點進行了很多創新的改進，請參考文章“AJAX，Comet and Jetty”（請參見 參考資源）。
控制信息與數據信息使用不同的 HTTP 連接
使用長連接時，存在一個很常見的場景：客戶端網頁需要關閉，而服務器端還處在讀取數據的堵塞狀態，客戶端需要及時通知服務器端關閉數據連接。服務器在收到關閉請求后首先要從讀取數據的阻塞狀態喚醒，然后釋放為這個客戶端分配的資源，再關閉連接。
所以在設計上，我們需要使客戶端的控制請求和數據請求使用不同的 HTTP 連接，才能使控制請求不會被阻塞。
在實現上，如果是基于 iframe 流方式的長連接，客戶端頁面需要使用兩個 iframe，一個是控制幀，用于往服務器端發送控制請求，控制請求能很快收到響應，不會被堵塞；一個是顯示幀，用于往服務器端發送長連接請求。如果是基于 AJAX 的長輪詢方式，客戶端可以異步地發出一個 XMLHttpRequest 請求，通知服務器端關閉數據連接。
在客戶和服務器之間保持“心跳”信息
在瀏覽器與服務器之間維持一個長連接會為通信帶來一些不確定性：因為數據傳輸是隨機的，客戶端不知道何時服務器才有數據傳送。服務器端需要確保當客戶端不再工作時，釋放為這個客戶端分配的資源，防止內存泄漏。因此需要一種機制使雙方知道大家都在正常運行。在實現上：
- 服務器端在阻塞讀時會設置一個時限，超時后阻塞讀調用會返回，同時發給客戶端沒有新數據到達的心跳信息。此時如果客戶端已經關閉，服務器往通道寫數據會出現異常，服務器端就會及時釋放為這個客戶端分配的資源。
- 如果客戶端使用的是基于 AJAX 的長輪詢方式；服務器端返回數據、關閉連接后，經過某個時限沒有收到客戶端的再次請求，會認為客戶端不能正常工作，會釋放為這個客戶端分配、維護的資源。
- 當服務器處理信息出現異常情況，需要發送錯誤信息通知客戶端，同時釋放資源、關閉連接。
Pushlet - 開源 Comet 框架
Pushlet 是一個開源的 Comet 框架，在設計上有很多值得借鑒的地方，對于開發輕量級的 Comet 應用很有參考價值。
觀察者模型
Pushlet 使用了觀察者模型：客戶端發送請求，訂閱感興趣的事件；服務器端為每個客戶端分配一個會話 ID 作為標記，事件源會把新產生的事件以多播的方式發送到訂閱者的事件隊列里。
客戶端 JavaScript 庫
pushlet 提供了基于 AJAX 的 JavaScript 庫文件用于實現長輪詢方式的“服務器推”；還提供了基于 iframe 的 JavaScript 庫文件用于實現流方式的“服務器推”。
JavaScript 庫做了很多封裝工作：
- 定義客戶端的通信狀態：
STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING； - 保存服務器分配的會話 ID，在建立連接之后的每次請求中會附上會話 ID 表明身份；
- 提供了
join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供頁面調用； - 提供了處理響應的 JavaScript 函數接口
onData()、onEvent()…
網頁可以很方便地使用這兩個 JavaScript 庫文件封裝的 API 與服務器進行通信。
客戶端與服務器端通信信息格式
pushlet 定義了一套客戶與服務器通信的信息格式，使用 XML 格式。定義了客戶端發送請求的類型：join、leave、subscribe、unsubscribe、listen、refresh；以及響應的事件類型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。
服務器端事件隊列管理
pushlet 在服務器端使用 Java Servlet 實現，其數據結構的設計框架仍可適用于 PHP、C 編寫的后臺客戶端。
Pushlet 支持客戶端自己選擇使用流、拉（長輪詢）、輪詢方式。服務器端根據客戶選擇的方式在讀取事件隊列（fetchEvents）時進行不同的處理。“輪詢”模式下 fetchEvents() 會馬上返回。”流“和”拉“模式使用阻塞的方式讀事件，如果超時，會發給客戶端發送一個沒有新信息收到的“heartbeat“事件，如果是“拉”模式，會把“heartbeat”與“refresh”事件一起傳給客戶端，通知客戶端重新發出請求、建立連接。
客戶服務器之間的會話管理
服務端在客戶端發送 join 請求時，會為客戶端分配一個會話 ID， 并傳給客戶端，然后客戶端就通過此會話 ID 標明身份發出subscribe 和 listen 請求。服務器端會為每個會話維護一個訂閱的主題集合、事件隊列。
服務器端的事件源會把新產生的事件以多播的方式發送到每個會話（即訂閱者）的事件隊列里。
回頁首
小結
本文介紹了如何在現有的技術基礎上選擇合適的方案開發一個“服務器推”的應用，最優的方案還是取決于應用需求的本身。相對于傳統的 Web 應用， 目前開發 Comet 應用還是具有一定的挑戰性。
“服務器推”存在廣泛的應用需求，為了使 Comet 模型適用于大規模的商業應用，以及方便用戶構建 Comet 應用，最近幾年，無論是服務器還是瀏覽器都出現了很多新技術，同時也出現了很多開源的 Comet 框架、協議。需求推動技術的發展，相信 Comet 的應用會變得和 AJAX 一樣普及。
vTCP連接的建立
v
第一次握手：客戶端TCP首先給服務器端TCP發送一個特殊的TCP數據
段。該數據段不包含應用層數據，并將頭部中的SYN位設置為1，所以該數
據段被稱為SYN數據段。另外，客戶選擇一個初始序列號SEQ，設SEQ＝x
并將這個編號放到初始的TCP SYN數據段的序列號字段中。該數據段被封
裝到一個IP數據報中，并發送給服務器。
第二次握手：一旦裝有TCP SYN數據段的IP數據報到達了服務器主機，服
務器將從該數據報中提取出TCP SYN數據段，給該連接分配TCP緩沖區和
變量，并給客戶TCP發送一個允許連接的數據段。這個允許連接的數據段
也不包含任何應用層數據。但是，它的頭部中裝載著3個重要信息。首先，
SYN被設置為1；其次，TCP數據段頭部的確認字段被設置為x＋1；最后，
服務器選擇自己的初始順序號，SEQ=y，并將該值放到TCP數據段頭部的
序列號字段中。
第三次握手：在接收到允許連接數據段之后，客戶也會給連接分配緩沖區
和變量。客戶端主機還會給服務器發送另一個數據段，對服務器的允許連
接數據段給出確認。
報錯：springmvc threw exception com.ibatis.sqlmap.client.SqlMapException: There is
no statement named 語句名 in this SqlMap.sqlmap-config.xml 中 必須加上這行：<settings cacheModelsEnabled="true" enhancementEnabled="false" lazyLoadingEnabled="false" maxRequests="3000" maxSessions="3000" maxTransactions="3000" useStatementNamespaces="true"/>
讓root用戶可以遠程登錄
--------------------------------------------------------------------------------
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'mypassword' WITH GRANT OPTION;
以前發現在Ubuntu重啟后，hosts 文件又恢復到了修改前，十分奇怪。
一開始覺得是Linux的問題，最近在Mac上同樣的現象又出現了。
查看 /etc/目錄下，發現了兩個一摸一樣的文件,hosts和hosts.ac ，vimdiff一下，居然一模一樣！
看來原因找到了。
Cisco AnyConnect 搗的鬼
仔細回想了一下，發現/ect/hosts.ac是出現在 VPN 客戶端:Cisco AnyConnect后,hosts.ac應該是any client的縮寫。
這貨每次在重啟后，都會把/etc/hosts重新覆蓋一遍。
所以,除非你同時修改了/etc/hosts.ac 文件，否則單獨只修改/etc/hosts都會被重置。
下面開始實驗證明一下
首先測試下做個軟鏈是否有效：
刪除原來hosts.ac sudo rm /etc/hosts.ac 建立軟鏈 sudo ln -s /etc/hosts.ac /etc/hosts
重啟后發現，兩個hosts文件都不在了。。。悲劇 。
嘗試反著操作
刪除原來hosts sudo rm /etc/hosts 建立軟鏈 sudo ln -s /etc/hosts /etc/hosts.ac
再次重啟，發現軟連接消失了，依舊變成了連個一模一樣的hosts.ac 。
實驗證明
每次重啟，hosts.ac都會重新復制給hosts，
所以如果你希望hosts保留的話，每次修改hosts后，請同時復制給hosts.ac文件
如果不小心被誤刪除了，可以使用原始的hosts文件內容恢復：
255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost
偷懶的解決方案
在BASH的PATH目錄下，創建mh腳本，以后通過這個腳本修改hosts文件
#!/bin/bash #!/bin/bash
modify hosts
if [ -f /etc/hosts ];then echo "/etc/hosts exists,back up to ~/hosts.bak" cp /etc/hosts ~/hosts.bak sudo rm /etc/hosts fi if [ ! -L /etc/hosts ];then echo "link /etc/hosts.ac => /etc/hosts" sudo ln -s /etc/hosts.ac /etc/hosts fi sudo vi /etc/hosts.ac
出錯如下：
New emulator found: emulator-5554
Waiting for HOME ('android.process.acore') to be launched...
解決方法：保持AVD，不要關閉，重新運行工程。
在網絡編程領域（注意不是Web編程），幾乎每天都與socket打交道。然而不知如何，國人竟把socket翻譯成了“套接字”。socket的原意是指電源插座，而“套接字”為何物？
雖然這種翻譯已經被絕大多數國人認可，可這也恰恰給網絡編程的入門及其本質的理解造成了難以理解的巨大惡果。還是先讓我們來看看插座吧。
對于電源插座，相信大家都不會陌生了。看看下面這個再簡單不過的生活經歷：
小王裝修房子，第一天，為了用電，必須找一根電纜從變電站把電引入家中。也就是家里用電的總來源要有啊。
第二天，小王買來了電冰箱，為了給電冰箱供電，必須先買一個插座，并把插座接到第一天引入的電源線上。剩下來就簡單了，因為有了插座(socket)，把冰箱的電源插頭插入就OK了。
第三天，熱愛計算機的小王買來了心愛的電腦，可這下就犯愁了，怎么供電呢？好辦，又買了一個插座(socket)并接到電源線上，把電腦的插頭插入socket，電腦終于可以正常使用了。
第四天，小王又買來了電視機，同樣一個socket，又讓電視機順利地工作了。
第五天，第六天...按照同樣的方法，小王通過一個又一個的插座(socket)，完成了所有電器的供電。
看完了這個例子，再想想網絡編程，簡直是如出一轍。
為了連上網絡，必須要有網卡（總電源），這樣網絡上的數據便可以到達你的計算機了。可是你的應用程序如何取得這些網絡數據呢，很簡單，建立一個socket，并連到網卡上，好了這下你就可以從插座里取得信息了。無論何時你想取得網絡數據只需連接一個socket即可。
看看，socket這個詞，用到網絡編程API上是何等的形象！足見創始人對網絡編程模型的準確把握和良苦用心。然而我們的翻譯者卻把這么好的一個術語弄成了“套接字”，本來很簡單直觀的網絡編程被蒙上了一層復雜深奧的迷霧。
注意：當然網絡編程中的Socket與電源插座有一定的差別，網絡中的socket種類和功能更多更強，但是其本質是一樣的。按照插座來理解網絡編程，將非常的自然清晰。
test
1.下載Array Networks提供的客戶端程序 array_vpnc.bin
sudo apt-get install libc6-i386 #64位系統也是這個包
wget http://q.pnq.cc/uploads/array_vpnc.bin
chmod a+x array_vpnc.bin
2.下載這個小腳本到同個目錄
wget http://q.pnq.cc/uploads/vpn-for-common.sh -O vpn.sh
chmod 700 vpn.sh
3.修改vpn.sh中的配置，將vpn_host、user、key修改為你的配置
vpn_host=your_vpn_server
user=your_user_name
key=your_static_passwd #密? ?中不變的部分
使用方法：
./vpn.sh
然后根據提示輸入，當看到這個提示時，就說明成功了：
array_vpnc: VPN TUNNEL SUCCESSFUL!
public class PerformanceTest {
public static void main(String[] args){
long time1 = System.currentTimeMillis();
Long sum=0L;
for(long i=0;i<Integer.MAX_VALUE;i++){
sum+=i;
}
System.out.println(sum);
long time2 = System.currentTimeMillis();
System.out.println((time2 - time1)/1000 + "秒。");
}
}
上面的代碼執行了28秒
public class PerformanceTest {
public static void main(String[] args){
long time1 = System.currentTimeMillis();
long sum=0L;
for(long i=0;i<Integer.MAX_VALUE;i++){
sum+=i;
}
System.out.println(sum);
long time2 = System.currentTimeMillis();
System.out.println((time2 - time1)/1000 + "秒。");
}
}
上面的代碼執行了7秒
第一段代碼構造了大約2的31次放的Long 實例
如果你用的SVNKit, 找到以下目錄并刪除.keyring文件.
[eclipsehome ]/"configuration"/org.eclipse .core.runtime