2011年6月27日
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泛型面試中，一開場(chǎng)你就會(huì)被問(wèn)到的問(wèn)題中的一個(gè)，主要集中在初級(jí)和中級(jí)面試中。那些擁有Java1.4或更早版本的開發(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之前的版本開發(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. 如何編寫一個(gè)泛型方法，讓它能接受泛型參數(shù)并返回泛型類型?
編寫泛型方法并不困難，你需要用泛型類型來(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中如何使用泛型編寫帶有參數(shù)的類?
這是上一道面試題的延伸。面試官可能會(huì)要求你用泛型編寫一個(gè)類型安全的類，而不是編寫一個(gè)泛型方法。關(guān)鍵仍然是使用泛型類型來(lái)代替原始類型，而且要使用JDK中采用的標(biāo)準(zhǔn)占位符。
7. 編寫一段泛型程序來(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)編寫了一個(gè)可運(yùn)行的JUnit測(cè)試，你也可以隨意編寫你自己的實(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一書中建議使用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í)所寫的代碼，只是更能確保類型安全而已。
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);
重寫方法的規(guī)則：
1、參數(shù)列表必須完全與被重寫的方法相同，否則不能稱其為重寫而是重載。
2、返回的類型必須一直與被重寫的方法的返回類型相同，否則不能稱其為重寫而是重載。
3、訪問(wèn)修飾符的限制一定要大于被重寫方法的訪問(wèn)修飾符（public>protected>default>private）
4、重寫方法一定不能拋出新的檢查異常或者比被重寫方法申明更加寬泛的檢查型異常。例如：
父類的一個(gè)方法申明了一個(gè)檢查異常IOException，在重寫這個(gè)方法是就不能拋出Exception,只能拋出IOException的子類異常，可以拋出非檢查異常。
而重載的規(guī)則：
1、必須具有不同的參數(shù)列表；
2、可以有不責(zé)罵的返回類型，只要參數(shù)列表不同就可以了；
3、可以有不同的訪問(wèn)修飾符；
4、可以拋出不同的異常；
重寫與重載的區(qū)別在于：
重寫多態(tài)性起作用，對(duì)調(diào)用被重載過(guò)的方法可以大大減少代碼的輸入量，同一個(gè)方法名只要往里面?zhèn)鬟f不同的參數(shù)就可以擁有不同的功能或返回值。
用好重寫和重載可以設(shè)計(jì)一個(gè)結(jié)構(gòu)清晰而簡(jiǎn)潔的類，可以說(shuō)重寫和重載在編寫代碼過(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.打開旺旺的聊天窗口
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)我們打開瀏覽器，在地址欄中輸入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ù)開始受到較多關(guān)注，Alex Russell（Dojo Toolkit 的項(xiàng)目 Lead）稱這種基于 HTTP 長(zhǎng)連接、無(wú)須在瀏覽器端安裝插件的“服務(wù)器推”技術(shù)為“Comet”。目前已經(jīng)出現(xiàn)了一些成熟的 Comet 應(yīng)用以及各種開源框架；一些 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)參見 參考資源）
回頁(yè)首
使用 Comet 模型開發(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)象：在客戶端如果打開超過(guò)兩個(gè)的 IE 窗口去訪問(wèn)同一個(gè)使用了長(zhǎng)連接的 Web 服務(wù)器，第三個(gè) IE 窗口的 HTTP 請(qǐng)求被前兩個(gè)窗口的長(zhǎng)連接阻塞。
所以在開發(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)參見 參考資源）。
控制信息與數(shù)據(jù)信息使用不同的 HTTP 連接
使用長(zhǎng)連接時(shí)，存在一個(gè)很常見的場(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ù)器往通道寫數(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 - 開源 Comet 框架
Pushlet 是一個(gè)開源的 Comet 框架，在設(shè)計(jì)上有很多值得借鑒的地方，對(duì)于開發(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 編寫的后臺(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ǔ)上選擇合適的方案開發(fā)一個(gè)“服務(wù)器推”的應(yīng)用，最優(yōu)的方案還是取決于應(yīng)用需求的本身。相對(duì)于傳統(tǒng)的 Web 應(yīng)用， 目前開發(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)了很多開源的 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;
以前發(fā)現(xiàn)在Ubuntu重啟后，hosts 文件又恢復(fù)到了修改前，十分奇怪。
一開始覺(jué)得是Linux的問(wèn)題，最近在Mac上同樣的現(xiàn)象又出現(xiàn)了。
查看 /etc/目錄下，發(fā)現(xiàn)了兩個(gè)一摸一樣的文件,hosts和hosts.ac ，vimdiff一下，居然一模一樣！
看來(lái)原因找到了。
Cisco AnyConnect 搗的鬼
仔細(xì)回想了一下，發(fā)現(xiàn)/ect/hosts.ac是出現(xiàn)在 VPN 客戶端:Cisco AnyConnect后,hosts.ac應(yīng)該是any client的縮寫。
這貨每次在重啟后，都會(huì)把/etc/hosts重新覆蓋一遍。
所以,除非你同時(shí)修改了/etc/hosts.ac 文件，否則單獨(dú)只修改/etc/hosts都會(huì)被重置。
下面開始實(shí)驗(yàn)證明一下
首先測(cè)試下做個(gè)軟鏈?zhǔn)欠裼行В?/h5>刪除原來(lái)hosts.ac sudo rm /etc/hosts.ac 建立軟鏈 sudo ln -s /etc/hosts.ac /etc/hosts
重啟后發(fā)現(xiàn)，兩個(gè)hosts文件都不在了。。。悲劇 。
嘗試反著操作
刪除原來(lái)hosts sudo rm /etc/hosts 建立軟鏈 sudo ln -s /etc/hosts /etc/hosts.ac
再次重啟，發(fā)現(xiàn)軟連接消失了，依舊變成了連個(gè)一模一樣的hosts.ac 。
實(shí)驗(yàn)證明
每次重啟，hosts.ac都會(huì)重新復(fù)制給hosts，
所以如果你希望hosts保留的話，每次修改hosts后，請(qǐng)同時(shí)復(fù)制給hosts.ac文件
如果不小心被誤刪除了，可以使用原始的hosts文件內(nèi)容恢復(fù)：
255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost
偷懶的解決方案
在BASH的PATH目錄下，創(chuàng)建mh腳本，以后通過(guò)這個(gè)腳本修改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
出錯(cuò)如下：
New emulator found: emulator-5554
Waiting for HOME ('android.process.acore') to be launched...
解決方法：保持AVD，不要關(guān)閉，重新運(yùn)行工程。
在網(wǎng)絡(luò)編程領(lǐng)域（注意不是Web編程），幾乎每天都與socket打交道。然而不知如何，國(guó)人竟把socket翻譯成了“套接字”。socket的原意是指電源插座，而“套接字”為何物？
雖然這種翻譯已經(jīng)被絕大多數(shù)國(guó)人認(rèn)可，可這也恰恰給網(wǎng)絡(luò)編程的入門及其本質(zhì)的理解造成了難以理解的巨大惡果。還是先讓我們來(lái)看看插座吧。
對(duì)于電源插座，相信大家都不會(huì)陌生了。看看下面這個(gè)再簡(jiǎn)單不過(guò)的生活經(jīng)歷：
小王裝修房子，第一天，為了用電，必須找一根電纜從變電站把電引入家中。也就是家里用電的總來(lái)源要有啊。
第二天，小王買來(lái)了電冰箱，為了給電冰箱供電，必須先買一個(gè)插座，并把插座接到第一天引入的電源線上。剩下來(lái)就簡(jiǎn)單了，因?yàn)橛辛瞬遄?socket)，把冰箱的電源插頭插入就OK了。
第三天，熱愛(ài)計(jì)算機(jī)的小王買來(lái)了心愛(ài)的電腦，可這下就犯愁了，怎么供電呢？好辦，又買了一個(gè)插座(socket)并接到電源線上，把電腦的插頭插入socket，電腦終于可以正常使用了。
第四天，小王又買來(lái)了電視機(jī)，同樣一個(gè)socket，又讓電視機(jī)順利地工作了。
第五天，第六天...按照同樣的方法，小王通過(guò)一個(gè)又一個(gè)的插座(socket)，完成了所有電器的供電。
看完了這個(gè)例子，再想想網(wǎng)絡(luò)編程，簡(jiǎn)直是如出一轍。
為了連上網(wǎng)絡(luò)，必須要有網(wǎng)卡（總電源），這樣網(wǎng)絡(luò)上的數(shù)據(jù)便可以到達(dá)你的計(jì)算機(jī)了。可是你的應(yīng)用程序如何取得這些網(wǎng)絡(luò)數(shù)據(jù)呢，很簡(jiǎn)單，建立一個(gè)socket，并連到網(wǎng)卡上，好了這下你就可以從插座里取得信息了。無(wú)論何時(shí)你想取得網(wǎng)絡(luò)數(shù)據(jù)只需連接一個(gè)socket即可。
看看，socket這個(gè)詞，用到網(wǎng)絡(luò)編程API上是何等的形象！足見創(chuàng)始人對(duì)網(wǎng)絡(luò)編程模型的準(zhǔn)確把握和良苦用心。然而我們的翻譯者卻把這么好的一個(gè)術(shù)語(yǔ)弄成了“套接字”，本來(lái)很簡(jiǎn)單直觀的網(wǎng)絡(luò)編程被蒙上了一層復(fù)雜深?yuàn)W的迷霧。
注意：當(dāng)然網(wǎng)絡(luò)編程中的Socket與電源插座有一定的差別，網(wǎng)絡(luò)中的socket種類和功能更多更強(qiáng)，但是其本質(zhì)是一樣的。按照插座來(lái)理解網(wǎng)絡(luò)編程，將非常的自然清晰。
test
1.下載Array Networks提供的客戶端程序 array_vpnc.bin
sudo apt-get install libc6-i386 #64位系統(tǒng)也是這個(gè)包
wget http://q.pnq.cc/uploads/array_vpnc.bin
chmod a+x array_vpnc.bin
2.下載這個(gè)小腳本到同個(gè)目錄
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
然后根據(jù)提示輸入，當(dāng)看到這個(gè)提示時(shí)，就說(shuō)明成功了：
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 + "秒。");
}
}
上面的代碼執(zhí)行了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 + "秒。");
}
}
上面的代碼執(zhí)行了7秒
第一段代碼構(gòu)造了大約2的31次放的Long 實(shí)例
如果你用的SVNKit, 找到以下目錄并刪除.keyring文件.
[eclipsehome ]/"configuration"/org.eclipse .core.runtime
<context-param>的作用:
web.xml的配置中<context-param>配置作用
1. 啟動(dòng)一個(gè)WEB項(xiàng)目的時(shí)候,容器(如:Tomcat)會(huì)去讀它的配置文件web.xml.讀兩個(gè)節(jié)點(diǎn): <listener></listener> 和 <context-param></context-param>
2.緊接著,容器創(chuàng)建一個(gè)ServletContext(上下文),這個(gè)WEB項(xiàng)目所有部分都將共享這個(gè)上下文.
3.容器將<context-param></context-param>轉(zhuǎn)化為鍵值對(duì),并交給ServletContext.
4.容器創(chuàng)建<listener></listener>中的類實(shí)例,即創(chuàng)建監(jiān)聽.
5.在監(jiān)聽中會(huì)有contextInitialized(ServletContextEvent args)初始化方法,在這個(gè)方法中獲得ServletContext = ServletContextEvent.getServletContext();
context-param的值 = ServletContext.getInitParameter("context-param的鍵");
6.得到這個(gè)context-param的值之后,你就可以做一些操作了.注意,這個(gè)時(shí)候你的WEB項(xiàng)目還沒(méi)有完全啟動(dòng)完成.這個(gè)動(dòng)作會(huì)比所有的Servlet都要早.
換句話說(shuō),這個(gè)時(shí)候,你對(duì)<context-param>中的鍵值做的操作,將在你的WEB項(xiàng)目完全啟動(dòng)之前被執(zhí)行.
7.舉例.你可能想在項(xiàng)目啟動(dòng)之前就打開數(shù)據(jù)庫(kù).
那么這里就可以在<context-param>中設(shè)置數(shù)據(jù)庫(kù)的連接方式,在監(jiān)聽類中初始化數(shù)據(jù)庫(kù)的連接.
8.這個(gè)監(jiān)聽是自己寫的一個(gè)類,除了初始化方法,它還有銷毀方法.用于關(guān)閉應(yīng)用前釋放資源.比如說(shuō)數(shù)據(jù)庫(kù)連接的關(guān)閉.
如:
<!-- 加載spring的配置文件 -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml,/WEB-INF/act
ion-servlet.xml,/WEB-INF/jason-servlet.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
又如: --->自定義context-param,且自定義listener來(lái)獲取這些信息
<context-param>
<param-name>urlrewrite</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>cluster</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>servletmapping</param-name>
<param-value>*.bbscs</param-value>
</context-param>
<context-param>
<param-name>poststoragemode</param-name>
<param-value>1</param-value>
</context-param>
<listener>
<listener-class>com.laoer.bbscs.web.servlet.SysListener</listener-class>
</listener>
public class SysListener extends HttpServlet implements ServletContextListener {
private static final Log logger = LogFactory.getLog(SysListener.class);
public void contextDestroyed(ServletContextEvent sce) {
//用于在容器關(guān)閉時(shí),操作
}
//用于在容器開啟時(shí),操作
public void contextInitialized(ServletContextEvent sce) {
String rootpath = sce.getServletContext().getRealPath("/");
System.out.println("-------------rootPath:"+rootpath);
if (rootpath != null) {
rootpath = rootpath.replaceAll("
\\\\", "/");
} else {
rootpath = "/";
}
if (!rootpath.endsWith("/")) {
rootpath = rootpath + "/";
}
Constant.ROOTPATH = rootpath;
logger.info("Application Run Path:" + rootpath);
String urlrewrtie =
sce.getServletContext().getInitParameter("urlrewrite"); boolean burlrewrtie = false;
if (urlrewrtie != null) {
burlrewrtie = Boolean.parseBoolean(urlrewrtie);
}
Constant.USE_URL_REWRITE = burlrewrtie;
logger.info("Use Urlrewrite:" + burlrewrtie);
其它略之....
}
}
/*最終輸出
-------------rootPath:D:\tomcat_bbs\webapps\BBSCS_8_0_3\
2009-06-09 21:51:46,526 [com.laoer.bbscs.web.servlet.SysListener]-[INFO]
Application Run Path:D:/tomcat_bbs/webapps/BBSCS_8_0_3/
2009-06-09 21:51:46,526 [com.laoer.bbscs.web.servlet.SysListener]-[INFO]
Use Urlrewrite:true
2009-06-09 21:51:46,526 [com.laoer.bbscs.web.servlet.SysListener]-[INFO]
Use Cluster:false
2009-06-09 21:51:46,526 [com.laoer.bbscs.web.servlet.SysListener]-[INFO]
SERVLET MAPPING:*.bbscs
2009-06-09 21:51:46,573 [com.laoer.bbscs.web.servlet.SysListener]-[INFO]
Post Storage Mode:1
*/
context-param和init-param區(qū)別
web.xml里面可以定義兩種參數(shù)：
(1)application范圍內(nèi)的參數(shù)，存放在servletcontext中，在web.xml中配置如下：
<context-param>
<param-name>context/param</param-name>
<param-value>avalible during application</param-value>
</context-param>
(2)servlet范圍內(nèi)的參數(shù)，只能在servlet的init()方法中取得，在web.xml中配置如下：
<servlet>
<servlet-name>MainServlet</servlet-name>
<servlet-class>com.wes.controller.MainServlet</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>avalible in servlet init()</param-value>
</init-param>
<load-on-startup>0</load-on-startup>
</servlet>
在servlet中可以通過(guò)代碼分別取用：
package com.wes.controller;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
public class MainServlet extends HttpServlet ...{
public MainServlet() ...{
super();
}
public void init() throws ServletException ...{
System.out.println("下面的兩個(gè)參數(shù)param1是在servlet中存放的");
System.out.println(this.getInitParameter("param1"));
System.out.println("下面的參數(shù)是存放在servletcontext中的");
System.out.println(getServletContext().getInitParameter("context/param"));
}
}
第一種參數(shù)在servlet里面可以通過(guò)getServletContext().getInitParameter("context/param")得到
第二種參數(shù)只能在servlet的init()方法中通過(guò)this.getInitParameter("param1")取得.