SQL標(biāo)準(zhǔn)定義了4類隔離級(jí)別，包括了一些具體規(guī)則，用來限定事務(wù)內(nèi)外的哪些改變是可見的，哪些是不可見的。低級(jí)別的隔離級(jí)一般支持更高的并發(fā)處理，并擁有更低的系統(tǒng)開銷。
Read Uncommitted（讀取未提交內(nèi)容）

       在該隔離級(jí)別，所有事務(wù)都可以看到其他未提交事務(wù)的執(zhí)行結(jié)果。本隔離級(jí)別很少用于實(shí)際應(yīng)用，因?yàn)樗男阅芤膊槐绕渌?jí)別好多少。讀取未提交的數(shù)據(jù)，也被稱之為臟讀（Dirty Read）。
Read Committed（讀取提交內(nèi)容）

       這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認(rèn)隔離級(jí)別（但不是MySQL默認(rèn)的）。它滿足了隔離的簡(jiǎn)單定義：一個(gè)事務(wù)只能看見已經(jīng)提交事務(wù)所做的改變。這種隔離級(jí)別 也支持所謂的不可重復(fù)讀（Nonrepeatable Read），因?yàn)橥皇聞?wù)的其他實(shí)例在該實(shí)例處理其間可能會(huì)有新的commit，所以同一select可能返回不同結(jié)果。
Repeatable Read（可重讀）

       這是MySQL的默認(rèn)事務(wù)隔離級(jí)別，它確保同一事務(wù)的多個(gè)實(shí)例在并發(fā)讀取數(shù)據(jù)時(shí)，會(huì)看到同樣的數(shù)據(jù)行。不過理論上，這會(huì)導(dǎo)致另一個(gè)棘手的問題：幻讀 （Phantom Read）。簡(jiǎn)單的說，幻讀指當(dāng)用戶讀取某一范圍的數(shù)據(jù)行時(shí)，另一個(gè)事務(wù)又在該范圍內(nèi)插入了新行，當(dāng)用戶再讀取該范圍的數(shù)據(jù)行時(shí)，會(huì)發(fā)現(xiàn)有新的“幻影” 行。InnoDB和Falcon存儲(chǔ)引擎通過多版本并發(fā)控制（MVCC，Multiversion Concurrency Control）機(jī)制解決了該問題。

Serializable（可串行化） 
       這是最高的隔離級(jí)別，它通過強(qiáng)制事務(wù)排序，使之不可能相互沖突，從而解決幻讀問題。簡(jiǎn)言之，它是在每個(gè)讀的數(shù)據(jù)行上加上共享鎖。在這個(gè)級(jí)別，可能導(dǎo)致大量的超時(shí)現(xiàn)象和鎖競(jìng)爭(zhēng)。

         這四種隔離級(jí)別采取不同的鎖類型來實(shí)現(xiàn)，若讀取的是同一個(gè)數(shù)據(jù)的話，就容易發(fā)生問題。例如：

         臟讀(Drity Read)：某個(gè)事務(wù)已更新一份數(shù)據(jù)，另一個(gè)事務(wù)在此時(shí)讀取了同一份數(shù)據(jù)，由于某些原因，前一個(gè)RollBack了操作，則后一個(gè)事務(wù)所讀取的數(shù)據(jù)就會(huì)是不正確的。

         不可重復(fù)讀(Non-repeatable read):在一個(gè)事務(wù)的兩次查詢之中數(shù)據(jù)不一致，這可能是兩次查詢過程中間插入了一個(gè)事務(wù)更新的原有的數(shù)據(jù)。

         幻讀(Phantom Read):在一個(gè)事務(wù)的兩次查詢中數(shù)據(jù)筆數(shù)不一致，例如有一個(gè)事務(wù)查詢了幾列(Row)數(shù)據(jù)，而另一個(gè)事務(wù)卻在此時(shí)插入了新的幾列數(shù)據(jù)，先前的事務(wù)在接下來的查詢中，就會(huì)發(fā)現(xiàn)有幾列數(shù)據(jù)是它先前所沒有的。

         在MySQL中，實(shí)現(xiàn)了這四種隔離級(jí)別，分別有可能產(chǎn)生問題如下所示：

下面，將利用MySQL的客戶端程序，分別測(cè)試幾種隔離級(jí)別。測(cè)試數(shù)據(jù)庫為test，表為tx；表結(jié)構(gòu)：

兩個(gè)命令行客戶端分別為A，B；不斷改變A的隔離級(jí)別，在B端修改數(shù)據(jù)。

（一）、將A的隔離級(jí)別設(shè)置為read uncommitted(未提交讀)

 在B未更新數(shù)據(jù)之前：

客戶端A：

B更新數(shù)據(jù)：

客戶端B：

客戶端A：

        經(jīng)過上面的實(shí)驗(yàn)可以得出結(jié)論，事務(wù)B更新了一條記錄，但是沒有提交，此時(shí)事務(wù)A可以查詢出未提交記錄。造成臟讀現(xiàn)象。未提交讀是最低的隔離級(jí)別。

（二）、將客戶端A的事務(wù)隔離級(jí)別設(shè)置為read committed(已提交讀)

 在B未更新數(shù)據(jù)之前：

B更新數(shù)據(jù)：

客戶端B：

客戶端A：

       經(jīng)過上面的實(shí)驗(yàn)可以得出結(jié)論，已提交讀隔離級(jí)別解決了臟讀的問題，但是出現(xiàn)了不可重復(fù)讀的問題，即事務(wù)A在兩次查詢的數(shù)據(jù)不一致，因?yàn)樵趦纱尾樵冎g事務(wù)B更新了一條數(shù)據(jù)。已提交讀只允許讀取已提交的記錄，但不要求可重復(fù)讀。

(三)、將A的隔離級(jí)別設(shè)置為repeatable read(可重復(fù)讀)

 在B未更新數(shù)據(jù)之前：

B更新數(shù)據(jù)：

客戶端B：

客戶端A：

B插入數(shù)據(jù)：

客戶端B：

客戶端A：

       由以上的實(shí)驗(yàn)可以得出結(jié)論，可重復(fù)讀隔離級(jí)別只允許讀取已提交記錄，而且在一個(gè)事務(wù)兩次讀取一個(gè)記錄期間，其他事務(wù)部的更新該記錄。但該事務(wù)不要求與其他事務(wù)可串行化。例如，當(dāng)一個(gè)事務(wù)可以找到由一個(gè)已提交事務(wù)更新的記錄，但是可能產(chǎn)生幻讀問題(注意是可能，因?yàn)閿?shù)據(jù)庫對(duì)隔離級(jí)別的實(shí)現(xiàn)有所差別)。像以上的實(shí)驗(yàn)，就沒有出現(xiàn)數(shù)據(jù)幻讀的問題。

(四)、將A的隔離級(jí)別設(shè)置為 可串行化 (Serializable)

A端打開事務(wù)，B端插入一條記錄

事務(wù)A端：

事務(wù)B端：

因?yàn)榇藭r(shí)事務(wù)A的隔離級(jí)別設(shè)置為serializable，開始事務(wù)后，并沒有提交，所以事務(wù)B只能等待。

事務(wù)A提交事務(wù)：

事務(wù)A端

事務(wù)B端

      
 serializable完全鎖定字段，若一個(gè)事務(wù)來查詢同一份數(shù)據(jù)就必須等待，直到前一個(gè)事務(wù)完成并解除鎖定為止 。是完整的隔離級(jí)別，會(huì)鎖定對(duì)應(yīng)的數(shù)據(jù)表格，因而會(huì)有效率的問題。

一、rsync的概述

rsync是類unix系統(tǒng)下的數(shù)據(jù)鏡像備份工具，從軟件的命名上就可以看出來了——remote sync。rsync是Linux系統(tǒng)下的文件同步和數(shù)據(jù)傳輸工具，它采用“rsync”算法，可以將一個(gè)客戶機(jī)和遠(yuǎn)程文件服務(wù)器之間的文件同步，也可以 在本地系統(tǒng)中將數(shù)據(jù)從一個(gè)分區(qū)備份到另一個(gè)分區(qū)上。如果rsync在備份過程中出現(xiàn)了數(shù)據(jù)傳輸中斷，恢復(fù)后可以繼續(xù)傳輸不一致的部分。rsync可以執(zhí)行 完整備份或增量備份。它的主要特點(diǎn)有：

1.可以鏡像保存整個(gè)目錄樹和文件系統(tǒng)；

2.可以很容易做到保持原來文件的權(quán)限、時(shí)間、軟硬鏈接；無須特殊權(quán)限即可安裝；

3.可以增量同步數(shù)據(jù)，文件傳輸效率高，因而同步時(shí)間短；

4.可以使用rcp、ssh等方式來傳輸文件，當(dāng)然也可以通過直接的socket連接；

5.支持匿名傳輸，以方便進(jìn)行網(wǎng)站鏡象等；

6.加密傳輸數(shù)據(jù)，保證了數(shù)據(jù)的安全性；

二、鏡像目錄與內(nèi)容

rsync -av duying  /tmp/test

查看/tmp/test目錄，我們可以看到此命令是把duying這個(gè)文件夾目錄連同內(nèi)容全部考到當(dāng)前目錄下了

rsync  -av duying/ /tmp/test         注意：比上一條命令多了符號(hào)“/” 

再次查看/tmp/test目錄，我們發(fā)現(xiàn)沒有duying這個(gè)目錄，只是看到了目錄中的內(nèi)容

三、增量備份本地文件

rsync -avzrtopgL  --progress /src /dst

-v是“--verbose”,即詳細(xì)模式輸出； -z表示“--compress”，即傳輸時(shí)對(duì)數(shù)據(jù)進(jìn)行壓縮處理；

-r表示“--recursive”，即對(duì)子目錄以遞歸的模式處理；-t是“--time”，即保持文件時(shí)間信息；

-o表示“owner”，用來保持文件屬主信息；-p是“perms”，用來保持文件權(quán)限；

-g是“group”，用來保持文件的屬組信息；

--progress用于顯示數(shù)據(jù)鏡像同步的過程；

四、鏡像同步備份文件

rsync -avzrtopg --progress --delete /src  /dst

--delete選項(xiàng)指定以rsync服務(wù)器端為基礎(chǔ)進(jìn)行數(shù)據(jù)鏡像同步，也就是要保持rsync服務(wù)器端目錄與客戶端目錄的完全一致；

--exclude選項(xiàng)用于排除不需要傳輸?shù)奈募愋停?/p>

五、設(shè)置定時(shí)備份策略

crontab -e

30 3 * * * rsync -avzrtopg  --progress  --delete  --exclude "*access*"

--exclude "*debug*"  /src /dst

如果文件比較大，可使用nohup將進(jìn)程放到后臺(tái)執(zhí)行。

nohup rsync -avzrtopgL  --progress /data/opt /data2/  >/var/log/$(date +%Y%m%d).mail.log & 

六、rsync的優(yōu)點(diǎn)與不足

與傳統(tǒng)的cp、tar備份方式對(duì)比，rsync具有安全性高、備份迅速、支持增量備份等優(yōu)點(diǎn)，通過rsync可以解決對(duì)實(shí)時(shí)性要求不高的數(shù)據(jù)備份需求，例如，定期地備份文件服務(wù)器數(shù)據(jù)到遠(yuǎn)端服務(wù)器，對(duì)本地磁盤定期進(jìn)行數(shù)據(jù)鏡像等。

但是隨著系統(tǒng)規(guī)模的不斷擴(kuò)大，rsync的缺點(diǎn)逐漸被暴露了出來。首先，rsync做數(shù)據(jù)同步時(shí)，需要掃描所有文件后進(jìn)行對(duì)比，然后進(jìn)行差量傳輸。如果文 件很大，掃面文件是非常耗時(shí)的，而且發(fā)生變化的文件往往是很少一部分，因此rsync是非常低效的方式。其次，rsync不能實(shí)時(shí)監(jiān)測(cè)、同步數(shù)據(jù)，雖然它 可以通過Linux守護(hù)進(jìn)程的方式觸發(fā)同步，但是兩次觸發(fā)動(dòng)作一定會(huì)有時(shí)間差，可能導(dǎo)致服務(wù)器端和客戶端數(shù)據(jù)出現(xiàn)不一致。

轉(zhuǎn)自：http://blog.sina.com.cn/s/blog_6954b9a901011esn.html

     Linux下如何查看版本信息， 包括位數(shù)、版本信息以及CPU內(nèi)核信息、CPU具體型號(hào)等等，整個(gè)CPU信息一目了然。

1. 在項(xiàng)目上右鍵進(jìn)入Properties,選擇Deployment Assembly，再點(diǎn)擊Add...,如下圖所示：
   
   ２.然后在彈出的窗口中，選擇Java Build Path Entries，點(diǎn)擊Next,如下圖所示：
   
   
   
   3.選擇你要你引入的UserLibrary，點(diǎn)擊Finish即可
   
   注意：如果在Java Web Project引入了其它Java Project,默認(rèn)引用的Java　Project的編譯后字節(jié)碼是不會(huì)部署到WEB-INF/class下的，此時(shí)需要使用上面的Project進(jìn)行導(dǎo)出．

原文：http://hg.rabbitmq.com/rabbitmq-management/raw-file/3646dee55e02/priv/www-api/help.html

介紹

除了幫助頁面，所有URIs只會(huì)服務(wù)application/json類型的資源，并且需要HTTP基礎(chǔ)認(rèn)證(使用標(biāo)準(zhǔn)RabbitMQ用戶數(shù)據(jù)庫). 默認(rèn)用戶是guest/guest.

大多數(shù)URIs需要虛擬主機(jī)名稱作為其路徑的一部分, 因?yàn)槊Q是虛擬主機(jī)的唯一標(biāo)識(shí)符對(duì)象. 默認(rèn)虛擬主機(jī)稱為"/", 它需要編碼為"%2f".

PUT一個(gè)資源會(huì)對(duì)其進(jìn)行創(chuàng)建. 你上傳的JSON對(duì)象必須有某個(gè)鍵keys (下面文檔有描述)，其它的鍵會(huì)被忽略. 缺失鍵會(huì)引發(fā)錯(cuò)誤.

在AMQP中，由于綁定沒有名稱或IDs，因此我們基于其所有屬性人工合成了一個(gè). 

由于一般情況下很難預(yù)測(cè)這個(gè)名字, 你可以通過POST一個(gè)工廠URI來創(chuàng)建綁定.查看下面的例子.

注意事項(xiàng)

• arguments 字段會(huì)被忽略.你不創(chuàng)建一個(gè)隊(duì)列,交換器或使用參數(shù)進(jìn)行綁定. 帶有參數(shù)的隊(duì)列，交換器或綁定也不會(huì)顯示這些參數(shù)．
• 權(quán)限偶爾才需要強(qiáng)制執(zhí)行.如果一個(gè)用戶能用HTTP API進(jìn)行認(rèn)證，那么它們可以做任何事情.
• 從GET請(qǐng)求中返回的對(duì)象中包含許多與監(jiān)控相關(guān)的信息. 它們是無證實(shí)的，并且將來可能要發(fā)生變化.

示例

下面有幾個(gè)快速例子,它們使用了Unix命令行工具curl:

• 獲取虛擬主機(jī)列表:

  $ curl -i -u guest:guest http://localhost:55672/api/vhosts 
  HTTP/1.1 200 OK 
  Server: MochiWeb/1.1 WebMachine/1.7 (participate in the frantic) 
  Date: Tue, 31 Aug 2010 15:46:59 GMT 
  Content-Type: application/json 
  Content-Length: 5  
  ["/"]

• 創(chuàng)建一個(gè)新虛擬主機(jī):

  $ curl -i -u guest:guest -H "content-type:application/json" \   -XPUT http://localhost:55672/api/vhosts/foo 
  HTTP/1.1 204 No Content 
  Server: MochiWeb/1.1 WebMachine/1.7 (participate in the frantic) 
  Date: Fri, 27 Aug 2010 16:56:00 GMT 
  Content-Type: application/json 
  Content-Length: 0

  注意: 你必須將mime類型指定為application/json.

  Note: 在上傳的JSON對(duì)象中，對(duì)象名稱是不需要的，因?yàn)樗呀?jīng)包含在了URI中. 由于一個(gè)虛擬主機(jī)除了名稱外沒有其它屬性，這意味著你完全不需要指定一個(gè)body.

• 在默認(rèn)虛擬主機(jī)中創(chuàng)建一個(gè)新的交換器:

  $ curl -i -u guest:guest -H "content-type:application/json" \   -XPUT -d'{"type":"direct","auto_delete":false,"durable":true,"arguments":[]}' \   http://localhost:55672/api/exchanges/%2f/my-new-exchange 
  HTTP/1.1 204 No Content 
  Server: MochiWeb/1.1 WebMachine/1.7 (participate in the frantic) 
  Date: Fri, 27 Aug 2010 17:04:29 GMT 
  Content-Type: application/json 
  Content-Length: 0

  注意: 在PUT或DELETE的響應(yīng)中， 除非失敗了，否則我們絕不會(huì)返回一個(gè)body.

• 再刪除它:

  $ curl -i -u guest:guest -H "content-type:application/json" \   -XDELETE http://localhost:55672/api/exchanges/%2f/my-new-exchange 
  HTTP/1.1 204 No Content 
  Server: MochiWeb/1.1 WebMachine/1.7 (participate in the frantic) 
  Date: Fri, 27 Aug 2010 17:05:30 GMT 
  Content-Type: application/json 
  Content-Length: 0

參考

{"type":"direct","auto_delete":false,"durable":true,"arguments":[]}

{"auto_delete":false,"durable":true,"arguments":[]}

{"routing_key":"my_routing_key","arguments":[]}

{"password":"secret"}

{"scope":"client","configure":".*","write":".*","read":".*"}

rabbitmqctl list_exchanges -p /myvhost name type

rabbitmqctl list_bindings -p /myvhost exchange_name queue_name

rabbitmqctl list_connections send_pend port

rabbitmqctl list_channels connection messages_unacknowledged

rabbitmqctl status

rabbitmqctl report > server_report.txt

rabbitmqctl eval 'node().'

• 使 client 連接與程序相關(guān)聯(lián)
• 使用細(xì)粒度的權(quán)限
• 憑據(jù)翻滾(如. 周期性地或遭到破壞的情況下)

• 至少有128 MB
• 當(dāng)RAM達(dá)到4GB時(shí)，可配置為75%的RAM限制
• 當(dāng)RAM達(dá)到4GB－8GB時(shí)，可配置為80%的RAM限制
• 當(dāng)RAM達(dá)到8GB－16GB時(shí)，可配置為85%的RAM限制
• 當(dāng)RAM大于16GB時(shí)，可配置為90%的RAM限制

• 至少有2 GB
• 當(dāng)限制為1到8GB的RAM時(shí)，可配置為RAM限制的50％
• 當(dāng)限制為8到32GB的RAM時(shí)，可配置為RAM限制的40%
• 當(dāng)限制超過32GB的RAM時(shí)，可配置為RAM限制的30%

• 希望的吞吐量
• 希望的復(fù)制( mirrors的數(shù)目)
• 數(shù)據(jù)局部性

原文：http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html

學(xué)習(xí)如何在你的應(yīng)用程序中集成WebSockets.

Published April 2013

對(duì)于許多基于客戶端－服務(wù)器程序來說，老的HTTP 請(qǐng)求-響應(yīng)模型已經(jīng)有它的局限性. 信息必須通過多次請(qǐng)求才能將其從服務(wù)端傳送到客戶端.

過去許多的黑客使用某些技術(shù)來繞過這個(gè)問題，例如：長(zhǎng)輪詢(long polling)、基于 HTTP 長(zhǎng)連接的服務(wù)器推技術(shù)(Comet). 

在2011年, IETF發(fā)布了標(biāo)準(zhǔn)WebSocket協(xié)議－RFC 6455. 從那時(shí)起，大多數(shù)Web瀏覽器都實(shí)現(xiàn)了支持WebSocket協(xié)議的客戶端APIs.同時(shí)，許多Java 包也開始實(shí)現(xiàn)了WebSocket協(xié)議.

WebSocket協(xié)議利用HTTP升級(jí)技術(shù)來將HTTP連接升級(jí)到WebSocket. 一旦升級(jí)后，連接就有了在兩個(gè)方向上相互獨(dú)立(全雙式)發(fā)送消息(數(shù)據(jù)楨)的能力. 

不需要headers 或cookies,這大大降低了所需的帶寬. 通常，WebSockets來周期性地發(fā)送小消息 (例如，幾個(gè)字節(jié)). 

JSR 356

JSR 356, WebSocket的Java API, 明確規(guī)定了API，當(dāng)Java開發(fā)者需要在應(yīng)用程序中集成WebSocket時(shí)，就可以使用此API—服務(wù)端和客戶端均可. 每個(gè)聲明兼容JSR 356的WebSocket協(xié)議，都必須實(shí)現(xiàn)這個(gè)API. 

因此，開發(fā)人員可以自己編寫?yīng)毩⒂诘讓覹ebSocket實(shí)現(xiàn)的WebSocket應(yīng)用。這是一個(gè)巨大的好處，因?yàn)樗梢苑乐构?yīng)商鎖定，并允許更多的選擇、自由的庫、應(yīng)用程序服務(wù)器。

JSR 356是即將到來的java EE 7標(biāo)準(zhǔn)的一部分，因此，所有與Java EE 7兼容的應(yīng)用服務(wù)器都有JSR 365標(biāo)準(zhǔn)WebSocket的實(shí)現(xiàn).一旦建立，WebSocket客戶端和服務(wù)器節(jié)點(diǎn)已經(jīng)是對(duì)稱的了。客戶端API與服務(wù)器端API的區(qū)別是很小的，JSR 356定義的Java client API只是Java EE7完整API的子集.

客戶段－服務(wù)器端程序使用WebSockets，通常會(huì)包含一個(gè)服務(wù)器組件和多個(gè)客戶端組件, 如圖１所示:

圖1

在這個(gè)例子中，server application 是通過Java編寫的,WebSocket 協(xié)議細(xì)節(jié)是由包含在Java EE 7容器中JSR 356 實(shí)現(xiàn)來處理的.

JavaFX 客戶端可依賴任何與JSR 356兼容的客戶端實(shí)現(xiàn)來處理WebSocket協(xié)議問題. 

其它客戶端(如,iOS 客戶端和HTML5客戶端)可使用其它 (非Java)與RFC6455兼容的實(shí)現(xiàn)來與server application通信.

編程模型

JSR 356定義的專家小組,希望支持Java EE開發(fā)人員常用的模式和技術(shù)。因此,JSR 356使用了注釋和注入。

一般來說，支持兩種編程模型:

• 注解驅(qū)動(dòng)(annotation-driven). 通過使用注解POJOs, 開發(fā)者可與WebSocket生命周期事件交互.
• 接口驅(qū)動(dòng)(interface-driven). 開發(fā)者可實(shí)現(xiàn)Endpoint接口和與生命周期交互的方法.

生命周期事件

典型的WebSocket 交互生命周期如下:

• 一端 (客戶端) 通過發(fā)送HTTP握手請(qǐng)求來初始化連接.
• 其它端(服務(wù)端) 回復(fù)握手響應(yīng).
• 建立連接.從現(xiàn)在開始，連接是完全對(duì)稱的.
• 兩端都可發(fā)送和接收消息.
• 其中一端關(guān)閉連接.

大部分WebSocket生命周期事件都與Java方法對(duì)應(yīng)，不管是 annotation-driven 還是interface-driven.

Annotation-Driven 方式

接受WebSocket請(qǐng)求的端點(diǎn)可以是以 @ServerEndpoint 注解的POJO. 

此注解告知容器，此類應(yīng)該被認(rèn)為是WebSocket端點(diǎn). 

必須的value 元素指定了WebSocket端點(diǎn)的路徑.

考慮下面的代碼片斷:

@ServerEndpoint("/hello")  public class MyEndpoint { } 

此代碼將會(huì)以相對(duì)路徑hello來發(fā)布一個(gè)端點(diǎn).在后續(xù)方法調(diào)用中，此路徑可攜帶路徑參數(shù)，如： /hello/{userid}是一個(gè)有效路徑，在這里{userid} 的值，可在生命周期方法使用@PathParam 注解獲取.

在GlassFish中，如果你的應(yīng)用程序是用上下文mycontextroot 部署的，且在localhost的8080端口上監(jiān)聽, WebSocket可通過使用ws://localhost:8080/mycontextroot/hello來訪問.

初始化WebSocket連接的端點(diǎn)可以是以 @ClientEndpoint 注解的POJO.@ClientEndpoint 和 @ServerEndpoint的主要區(qū)別是ClientEndpoint 不接受路徑路值元素，因?yàn)樗O(jiān)聽進(jìn)來的請(qǐng)求。

@ClientEndpoint  public class MyClientEndpoint {} 

Java中使用注解驅(qū)動(dòng)POJO方式來初始化WebSocket連接，可通過如下代碼來完成:

javax.websocket.WebSocketContainer container = javax.websocket.ContainerProvider.getWebSocketContainer();  container.conntectToServer(MyClientEndpoint.class, new URI("ws://localhost:8080/tictactoeserver/endpoint")); 

此后，以 @ServerEndpoint 或@ClientEndpoint 注解的類都稱為注解端點(diǎn).

一旦建立了WebSocket連接 ，就會(huì)創(chuàng)建 Session，并且會(huì)調(diào)用注解端點(diǎn)中以@OnOpen注解的方法. 

此方法包含了幾個(gè)參數(shù):

• javax.websocket.Session 參數(shù), 代表創(chuàng)建的Session
• EndpointConfig 實(shí)例包含了關(guān)于端點(diǎn)配置的信息
• ０個(gè)或多個(gè)以 @PathParam注解的字符串參數(shù),指的是端點(diǎn)路徑的path參數(shù)

下面的方法實(shí)現(xiàn)了當(dāng)打開WebSocket時(shí)，將會(huì)打印session的標(biāo)識(shí)符:

@OnOpen public void myOnOpen (Session session) {    System.out.println ("WebSocket opened: "+session.getId()); } 

Session實(shí)例只要WebSocket未關(guān)閉就會(huì)一直有效. Session類中包含了許多有意思的方法，以允許開發(fā)者獲取更多關(guān)于的信息。

同時(shí),Session 也包含了應(yīng)用程序特有的數(shù)據(jù)鉤子,即通過getUserProperties() 方法來返回 Map<String, Object>. 

這允許開發(fā)者可以使用session-和需要在多個(gè)方法調(diào)用間共享的應(yīng)用程序特定信息來填充Session實(shí)例.

i當(dāng)WebSocket端收到消息時(shí)，將會(huì)調(diào)用以@OnMessage注解的方法.以@OnMessage 注解的方法可包含下面的參數(shù):

• javax.websocket.Session 參數(shù).
• ０個(gè)或多個(gè)以 @PathParam注解的字符串參數(shù),指的是端點(diǎn)路徑的path參數(shù)
• 消息本身. 下面有可能消息類型描述.

當(dāng)其它端發(fā)送了文本消息時(shí)，下面的代碼片斷會(huì)打印消息內(nèi)容:

@OnMessage public void myOnMessage (String txt) {    System.out.println ("WebSocket received message: "+txt); }  

如果以@OnMessage i注解的方法返回值不是void, WebSocket實(shí)現(xiàn)會(huì)將返回值發(fā)送給其它端點(diǎn).下面的代碼片斷會(huì)將收到的文本消息以首字母大寫的形式發(fā)回給發(fā)送者:

@OnMessage public String myOnMessage (String txt) {    return txt.toUpperCase(); }  

另一種通過WebSocket連接來發(fā)送消息的代碼如下:

RemoteEndpoint.Basic other = session.getBasicRemote(); other.sendText ("Hello, world"); 

在這種方式中，我們從Session 對(duì)象開始，它可以從生命周期回調(diào)方法中獲取(例如,以 @OnOpen注解的方法).session實(shí)例上getBasicRemote() 方法返回的是WebSocket其它部分的代表RemoteEndpoint. RemoteEndpoint 實(shí)例可用于發(fā)送文本或其它類型的消息，后面有描述.

當(dāng)關(guān)閉WebSocket連接時(shí),將會(huì)調(diào)用@OnClose 注解的方法。此方法接受下面的參數(shù):

• javax.websocket.Session 參數(shù). 注意，一旦WebSocket真正關(guān)閉了，此參數(shù)就不能被使用了，這通常發(fā)生在@OnClose 注解方法返回之后.
• A javax.websocket.CloseReason 參數(shù)，用于描述關(guān)閉WebSocket的原因,如：正常關(guān)閉，協(xié)議錯(cuò)誤,服務(wù)過載等等.
• ０個(gè)或多個(gè)以 @PathParam注解的字符串參數(shù),指的是端點(diǎn)路徑的path參數(shù)

下面的代碼片段打印了WebSocket關(guān)閉的原因:

@OnClose public void myOnClose (CloseReason reason) {    System.out.prinlnt ("Closing a WebSocket due to "+reason.getReasonPhrase()); } 

完整情況下，這里還有一個(gè)生命周期注解:如果收到了錯(cuò)誤，將會(huì)調(diào)用 @OnError 注解的方法。

Interface-Driven 方式

annotation-driven 方式允許我們注解一個(gè)Java類，以及使用生命周期注解來注解方法. 

使用interface-driven方式,開發(fā)者可繼承javax.websocket.Endpoint 并覆蓋其中的onOpen, onClose, 以及onError 方法:

public class myOwnEndpoint extends javax.websocket.Endpoint {    public void onOpen(Session session, EndpointConfig config) {...}    public void onClose(Session session, CloseReason closeReason) {...}    public void onError (Session session, Throwable throwable) {...} } 

為了攔截消息，需要在onOpen實(shí)現(xiàn)中注冊(cè)一個(gè)javax.websocket.MessageHandler:

public void onOpen (Session session, EndpointConfig config) {    session.addMessageHandler (new MessageHandler() {...}); } 

MessageHandler 接口有兩個(gè)子接口: MessageHandler.Partial和 MessageHandler.Whole. 

MessageHandler.Partial 接口應(yīng)該用于當(dāng)開發(fā)者想要收到部分消息通知的時(shí)候,MessageHandler.Whole的實(shí)現(xiàn)應(yīng)該用于整個(gè)消息到達(dá)通知。

下面的代碼片斷會(huì)監(jiān)聽進(jìn)來的文件消息，并將文本信息轉(zhuǎn)換為大小版本后發(fā)回給其它端點(diǎn)：

public void onOpen (Session session, EndpointConfig config) {    final RemoteEndpoint.Basic remote = session.getBasicRemote();    session.addMessageHandler (new MessageHandler.Whole<String>() {       public void onMessage(String text) {                  try {                      remote.sendString(text.toUpperCase());                  } catch (IOException ioe) {                      // handle send failure here                  }              }     }); } 

消息類型，編碼器，解碼器

WebSocket的JavaAPI非常強(qiáng)大，因?yàn)樗试S發(fā)送任或接收任何對(duì)象作為WebSocket消息.

基本上，有三種不同類型的消息:

• 基于文本的消息
• 二進(jìn)制消息
• Pong 消息,它是WebSocket連接自身

當(dāng)使用interface-driven模式,每個(gè)session最多只能為這三個(gè)不同類型的消息注冊(cè)一個(gè)MessageHandler.

當(dāng)使用annotation-driven模式,針對(duì)不同類型的消息，只允許出現(xiàn)一個(gè)@onMessage 注解方法. 在注解方法中，消息內(nèi)容中允許的參數(shù)依賴于消息類型。

Javadoc for the @OnMessage annotation 明確指定了消息類型上允許出現(xiàn)的消息參數(shù):

• "如果方法用于處理文本消息: 
  
  
  • String 用于接收整個(gè)消息
  • Java 原型或等價(jià)的類用于接收整個(gè)消息并將其轉(zhuǎn)換為此類型
  • String 和 boolean 對(duì)用于部分接收消息
  • Reader 用于以阻塞流的方式接收整個(gè)消息
  • 端點(diǎn)的任何對(duì)象參數(shù)存在文本解碼器 (Decoder.Text 或 Decoder.TextStream).
• 如果方法用于處理二進(jìn)制消息: 
  
  
  • byte[] 或 ByteBuffer 用于接收整個(gè)消息
  • byte[] 和 boolean 對(duì), 或者 ByteBuffer 和boolean對(duì)用于部分接收消息
  • InputStream 用于按阻塞流的方式接收整個(gè)消息
  • 端點(diǎn)的任何對(duì)象參數(shù)存在二進(jìn)制解碼器(Decoder.Binary or Decoder.BinaryStream).
• 如果方法是用于處理pong消息: 
  
  
  • PongMessage 用于處理pong消息"

任何Java對(duì)象使用編碼器都可以編碼為基于文本或二進(jìn)制的消息.這種基于文本或二進(jìn)制的消息將轉(zhuǎn)輸?shù)狡渌它c(diǎn)，在其它端點(diǎn)，它可以解碼成Java對(duì)象－或者被另外的WebSocket 包解釋. 

通常情況下，XML或JSON用于來傳送WebSocket消息, 編碼/解碼然后會(huì)將Java對(duì)象編組成XML或JSON并在另一端解碼為Java對(duì)象.

encoder是以javax.websocket.Encoder 接口的實(shí)現(xiàn)來定義,decoder是以javax.websocket.Decoder 接口的實(shí)現(xiàn)來定義的. 

有時(shí)，端點(diǎn)實(shí)例必須知道encoders和decoders是什么.使用annotation-driven方式, 可向@ClientEndpoint 和 @ServerEndpoint l注解中的encode和decoder元素傳遞 encoders和decoders的列表。

Listing 1 中的代碼展示了如何注冊(cè)一個(gè) MessageEncoder 類(它定義了MyJavaObject實(shí)例到文本消息的轉(zhuǎn)換). MessageDecoder 是以相反的轉(zhuǎn)換來注冊(cè)的.

@ServerEndpoint(value="/endpoint", encoders = MessageEncoder.class, decoders= MessageDecoder.class) public class MyEndpoint { ... }  class MessageEncoder implements Encoder.Text<MyJavaObject> {    @override    public String encode(MyJavaObject obj) throws EncodingException {       ...    } }  class MessageDecoder implements Decoder.Text<MyJavaObject> {    @override     public MyJavaObject decode (String src) throws DecodeException {       ...    }     @override     public boolean willDecode (String src) {       // return true if we want to decode this String into a MyJavaObject instance    } } 

Listing 1

Encoder 接口有多個(gè)子接口:

• Encoder.Text 用于將Java對(duì)象轉(zhuǎn)成文本消息
• Encoder.TextStream 用于將Java對(duì)象添加到字符流中
• Encoder.Binary 用于將Java對(duì)象轉(zhuǎn)換成二進(jìn)制消息
• Encoder.BinaryStream 用于將Java對(duì)象添加到二進(jìn)制流中

類似地,Decoder 接口有四個(gè)子接口:

• Decoder.Text 用于將文本消息轉(zhuǎn)換成Java對(duì)象
• Decoder.TextStream 用于從字符流中讀取Java對(duì)象
• Decoder.Binary 用于將二進(jìn)制消息轉(zhuǎn)換成Java對(duì)象
• Decoder.BinaryStream 用于從二進(jìn)制流中讀取Java對(duì)象

結(jié)論

WebSocket Java API為Java開發(fā)者提供了標(biāo)準(zhǔn)API來集成IETF WebSocket標(biāo)準(zhǔn).通過這樣做，Web 客戶端或本地客戶端可使用任何WebSocket實(shí)現(xiàn)來輕易地與Java后端通信。

也可參考

• JSR 356 on jcp.org
• JSR 356 specification work on java.net
• Tyrus (JSR 356 Reference Implementation) on java.net
• JSR 342, the Java EE 7 umbrella specification on jcp.org
• GlassFish, the Reference Implementation for Java EE