SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。
Read Uncommitted（读取未提交内容）

       在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
Read Committed（读取提交内容）

       这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
Repeatable Read（可重读）

       这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

Serializable（可串行化） 
       这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

         这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：

         脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。

         不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。

         幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

         在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：

下面，将利用MySQL的客户端程序，分别测试几种隔离级别。测试数据库为test，表为tx；表结构：

两个命令行客户端分别为A，B；不断改变A的隔离级别，在B端修改数据。

（一）、将A的隔离级别设置为read uncommitted(未提交读)

 在B未更新数据之前：

客户端A：

B更新数据：

客户端B：

客户端A：

        经过上面的实验可以得出结论，事务B更新了一条记录，但是没有提交，此时事务A可以查询出未提交记录。造成脏读现象。未提交读是最低的隔离级别。

（二）、将客户端A的事务隔离级别设置为read committed(已提交读)

 在B未更新数据之前：

B更新数据：

客户端B：

客户端A：

       经过上面的实验可以得出结论，已提交读隔离级别解决了脏读的问题，但是出现了不可重复读的问题，即事务A在两次查询的数据不一致，因为在两次查询之间事务B更新了一条数据。已提交读只允许读取已提交的记录，但不要求可重复读。

(三)、将A的隔离级别设置为repeatable read(可重复读)

 在B未更新数据之前：

B更新数据：

客户端B：

客户端A：

B插入数据：

客户端B：

客户端A：

       由以上的实验可以得出结论，可重复读隔离级别只允许读取已提交记录，而且在一个事务两次读取一个记录期间，其他事务部的更新该记录。但该事务不要求与其他事务可串行化。例如，当一个事务可以找到由一个已提交事务更新的记录，但是可能产生幻读问题(注意是可能，因为数据库对隔离级别的实现有所差别)。像以上的实验，就没有出现数据幻读的问题。

(四)、将A的隔离级别设置为 可串行化 (Serializable)

A端打开事务，B端插入一条记录

事务A端：

事务B端：

因为此时事务A的隔离级别设置为serializable，开始事务后，并没有提交，所以事务B只能等待。

事务A提交事务：

事务A端

事务B端

      
 serializable完全锁定字段，若一个事务来查询同一份数据就必须等待，直到前一个事务完成并解除锁定为止 。是完整的隔离级别，会锁定对应的数据表格，因而会有效率的问题。

一、rsync的概述

rsync是类unix系统下的数据镜像备份工具，从软件的命名上就可以看出来了——remote sync。rsync是Linux系统下的文件同步和数据传输工具，它采用“rsync”算法，可以将一个客户机和远程文件服务器之间的文件同步，也可以 在本地系统中将数据从一个分区备份到另一个分区上。如果rsync在备份过程中出现了数据传输中断，恢复后可以继续传输不一致的部分。rsync可以执行 完整备份或增量备份。它的主要特点有：

1.可以镜像保存整个目录树和文件系统；

2.可以很容易做到保持原来文件的权限、时间、软硬链接；无须特殊权限即可安装；

3.可以增量同步数据，文件传输效率高，因而同步时间短；

4.可以使用rcp、ssh等方式来传输文件，当然也可以通过直接的socket连接；

5.支持匿名传输，以方便进行网站镜象等；

6.加密传输数据，保证了数据的安全性；

二、镜像目录与内容

rsync -av duying  /tmp/test

查看/tmp/test目录，我们可以看到此命令是把duying这个文件夹目录连同内容全部考到当前目录下了

rsync  -av duying/ /tmp/test         注意：比上一条命令多了符号“/” 

再次查看/tmp/test目录，我们发现没有duying这个目录，只是看到了目录中的内容

三、增量备份本地文件

rsync -avzrtopgL  --progress /src /dst

-v是“--verbose”,即详细模式输出； -z表示“--compress”，即传输时对数据进行压缩处理；

-r表示“--recursive”，即对子目录以递归的模式处理；-t是“--time”，即保持文件时间信息；

-o表示“owner”，用来保持文件属主信息；-p是“perms”，用来保持文件权限；

-g是“group”，用来保持文件的属组信息；

--progress用于显示数据镜像同步的过程；

四、镜像同步备份文件

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

--delete选项指定以rsync服务器端为基础进行数据镜像同步，也就是要保持rsync服务器端目录与客户端目录的完全一致；

--exclude选项用于排除不需要传输的文件类型；

五、设置定时备份策略

crontab -e

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

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

如果文件比较大，可使用nohup将进程放到后台执行。

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

六、rsync的优点与不足

与传统的cp、tar备份方式对比，rsync具有安全性高、备份迅速、支持增量备份等优点，通过rsync可以解决对实时性要求不高的数据备份需求，例如，定期地备份文件服务器数据到远端服务器，对本地磁盘定期进行数据镜像等。

但是随着系统规模的不断扩大，rsync的缺点逐渐被暴露了出来。首先，rsync做数据同步时，需要扫描所有文件后进行对比，然后进行差量传输。如果文 件很大，扫面文件是非常耗时的，而且发生变化的文件往往是很少一部分，因此rsync是非常低效的方式。其次，rsync不能实时监测、同步数据，虽然它 可以通过Linux守护进程的方式触发同步，但是两次触发动作一定会有时间差，可能导致服务器端和客户端数据出现不一致。

转自：http://blog.sina.com.cn/s/blog_6954b9a901011esn.html

     Linux下如何查看版本信息， 包括位数、版本信息以及CPU内核信息、CPU具体型号等等，整个CPU信息一目了然。

1. 在项目上右键进入Properties,选择Deployment Assembly，再点击Add...,如下图所示：
   
   ２.然后在弹出的窗口中，选择Java Build Path Entries，点击Next,如下图所示：
   
   
   
   3.选择你要你引入的UserLibrary，点击Finish即可
   
   注意：如果在Java Web Project引入了其它Java Project,默认引用的Java　Project的编译后字节码是不会部署到WEB-INF/class下的，此时需要使用上面的Project进行导出．

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

介绍

除了帮助页面，所有URIs只会服务application/json类型的资源，并且需要HTTP基础认证(使用标准RabbitMQ用户数据库). 默认用户是guest/guest.

大多数URIs需要虚拟主机名称作为其路径的一部分, 因为名称是虚拟主机的唯一标识符对象. 默认虚拟主机称为"/", 它需要编码为"%2f".

PUT一个资源会对其进行创建. 你上传的JSON对象必须有某个键keys (下面文档有描述)，其它的键会被忽略. 缺失键会引发错误.

在AMQP中，由于绑定没有名称或IDs，因此我们基于其所有属性人工合成了一个. 

由于一般情况下很难预测这个名字, 你可以通过POST一个工厂URI来创建绑定.查看下面的例子.

注意事项

• arguments 字段会被忽略.你不创建一个队列,交换器或使用参数进行绑定. 带有参数的队列，交换器或绑定也不会显示这些参数．
• 权限偶尔才需要强制执行.如果一个用户能用HTTP API进行认证，那么它们可以做任何事情.
• 从GET请求中返回的对象中包含许多与监控相关的信息. 它们是无证实的，并且将来可能要发生变化.

示例

下面有几个快速例子,它们使用了Unix命令行工具curl:

• 获取虚拟主机列表:

  $ 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  
  ["/"]

• 创建一个新虚拟主机:

  $ 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对象中，对象名称是不需要的，因为它已经包含在了URI中. 由于一个虚拟主机除了名称外没有其它属性，这意味着你完全不需要指定一个body.

• 在默认虚拟主机中创建一个新的交换器:

  $ 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的响应中， 除非失败了，否则我们绝不会返回一个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 连接与程序相关联
• 使用细粒度的权限
• 凭据翻滚(如. 周期性地或遭到破坏的情况下)

• 至少有128 MB
• 当RAM达到4GB时，可配置为75%的RAM限制
• 当RAM达到4GB－8GB时，可配置为80%的RAM限制
• 当RAM达到8GB－16GB时，可配置为85%的RAM限制
• 当RAM大于16GB时，可配置为90%的RAM限制

• 至少有2 GB
• 当限制为1到8GB的RAM时，可配置为RAM限制的50％
• 当限制为8到32GB的RAM时，可配置为RAM限制的40%
• 当限制超过32GB的RAM时，可配置为RAM限制的30%

• 希望的吞吐量
• 希望的复制( mirrors的数目)
• 数据局部性

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

学习如何在你的应用程序中集成WebSockets.

Published April 2013

对于许多基于客户端－服务器程序来说，老的HTTP 请求-响应模型已经有它的局限性. 信息必须通过多次请求才能将其从服务端传送到客户端.

过去许多的黑客使用某些技术来绕过这个问题，例如：长轮询(long polling)、基于 HTTP 长连接的服务器推技术(Comet). 

在2011年, IETF发布了标准WebSocket协议－RFC 6455. 从那时起，大多数Web浏览器都实现了支持WebSocket协议的客户端APIs.同时，许多Java 包也开始实现了WebSocket协议.

WebSocket协议利用HTTP升级技术来将HTTP连接升级到WebSocket. 一旦升级后，连接就有了在两个方向上相互独立(全双式)发送消息(数据桢)的能力. 

不需要headers 或cookies,这大大降低了所需的带宽. 通常，WebSockets来周期性地发送小消息 (例如，几个字节). 

JSR 356

JSR 356, WebSocket的Java API, 明确规定了API，当Java开发者需要在应用程序中集成WebSocket时，就可以使用此API—服务端和客户端均可. 每个声明兼容JSR 356的WebSocket协议，都必须实现这个API. 

因此，开发人员可以自己编写独立于底层WebSocket实现的WebSocket应用。这是一个巨大的好处，因为它可以防止供应商锁定，并允许更多的选择、自由的库、应用程序服务器。

JSR 356是即将到来的java EE 7标准的一部分，因此，所有与Java EE 7兼容的应用服务器都有JSR 365标准WebSocket的实现.一旦建立，WebSocket客户端和服务器节点已经是对称的了。客户端API与服务器端API的区别是很小的，JSR 356定义的Java client API只是Java EE7完整API的子集.

客户段－服务器端程序使用WebSockets，通常会包含一个服务器组件和多个客户端组件, 如图１所示:

图1

在这个例子中，server application 是通过Java编写的,WebSocket 协议细节是由包含在Java EE 7容器中JSR 356 实现来处理的.

JavaFX 客户端可依赖任何与JSR 356兼容的客户端实现来处理WebSocket协议问题. 

其它客户端(如,iOS 客户端和HTML5客户端)可使用其它 (非Java)与RFC6455兼容的实现来与server application通信.

编程模型

JSR 356定义的专家小组,希望支持Java EE开发人员常用的模式和技术。因此,JSR 356使用了注释和注入。

一般来说，支持两种编程模型:

• 注解驱动(annotation-driven). 通过使用注解POJOs, 开发者可与WebSocket生命周期事件交互.
• 接口驱动(interface-driven). 开发者可实现Endpoint接口和与生命周期交互的方法.

生命周期事件

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

• 一端 (客户端) 通过发送HTTP握手请求来初始化连接.
• 其它端(服务端) 回复握手响应.
• 建立连接.从现在开始，连接是完全对称的.
• 两端都可发送和接收消息.
• 其中一端关闭连接.

大部分WebSocket生命周期事件都与Java方法对应，不管是 annotation-driven 还是interface-driven.

Annotation-Driven 方式

接受WebSocket请求的端点可以是以 @ServerEndpoint 注解的POJO. 

此注解告知容器，此类应该被认为是WebSocket端点. 

必须的value 元素指定了WebSocket端点的路径.

考虑下面的代码片断:

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

此代码将会以相对路径hello来发布一个端点.在后续方法调用中，此路径可携带路径参数，如： /hello/{userid}是一个有效路径，在这里{userid} 的值，可在生命周期方法使用@PathParam 注解获取.

在GlassFish中，如果你的应用程序是用上下文mycontextroot 部署的，且在localhost的8080端口上监听, WebSocket可通过使用ws://localhost:8080/mycontextroot/hello来访问.

初始化WebSocket连接的端点可以是以 @ClientEndpoint 注解的POJO.@ClientEndpoint 和 @ServerEndpoint的主要区别是ClientEndpoint 不接受路径路值元素，因为它监听进来的请求。

@ClientEndpoint  public class MyClientEndpoint {} 

Java中使用注解驱动POJO方式来初始化WebSocket连接，可通过如下代码来完成:

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

此后，以 @ServerEndpoint 或@ClientEndpoint 注解的类都称为注解端点.

一旦建立了WebSocket连接 ，就会创建 Session，并且会调用注解端点中以@OnOpen注解的方法. 

此方法包含了几个参数:

• javax.websocket.Session 参数, 代表创建的Session
• EndpointConfig 实例包含了关于端点配置的信息
• ０个或多个以 @PathParam注解的字符串参数,指的是端点路径的path参数

下面的方法实现了当打开WebSocket时，将会打印session的标识符:

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

Session实例只要WebSocket未关闭就会一直有效. Session类中包含了许多有意思的方法，以允许开发者获取更多关于的信息。

同时,Session 也包含了应用程序特有的数据钩子,即通过getUserProperties() 方法来返回 Map<String, Object>. 

这允许开发者可以使用session-和需要在多个方法调用间共享的应用程序特定信息来填充Session实例.

i当WebSocket端收到消息时，将会调用以@OnMessage注解的方法.以@OnMessage 注解的方法可包含下面的参数:

• javax.websocket.Session 参数.
• ０个或多个以 @PathParam注解的字符串参数,指的是端点路径的path参数
• 消息本身. 下面有可能消息类型描述.

当其它端发送了文本消息时，下面的代码片断会打印消息内容:

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

如果以@OnMessage i注解的方法返回值不是void, WebSocket实现会将返回值发送给其它端点.下面的代码片断会将收到的文本消息以首字母大写的形式发回给发送者:

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

另一种通过WebSocket连接来发送消息的代码如下:

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

在这种方式中，我们从Session 对象开始，它可以从生命周期回调方法中获取(例如,以 @OnOpen注解的方法).session实例上getBasicRemote() 方法返回的是WebSocket其它部分的代表RemoteEndpoint. RemoteEndpoint 实例可用于发送文本或其它类型的消息，后面有描述.

当关闭WebSocket连接时,将会调用@OnClose 注解的方法。此方法接受下面的参数:

• javax.websocket.Session 参数. 注意，一旦WebSocket真正关闭了，此参数就不能被使用了，这通常发生在@OnClose 注解方法返回之后.
• A javax.websocket.CloseReason 参数，用于描述关闭WebSocket的原因,如：正常关闭，协议错误,服务过载等等.
• ０个或多个以 @PathParam注解的字符串参数,指的是端点路径的path参数

下面的代码片段打印了WebSocket关闭的原因:

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

完整情况下，这里还有一个生命周期注解:如果收到了错误，将会调用 @OnError 注解的方法。

Interface-Driven 方式

annotation-driven 方式允许我们注解一个Java类，以及使用生命周期注解来注解方法. 

使用interface-driven方式,开发者可继承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实现中注册一个javax.websocket.MessageHandler:

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

MessageHandler 接口有两个子接口: MessageHandler.Partial和 MessageHandler.Whole. 

MessageHandler.Partial 接口应该用于当开发者想要收到部分消息通知的时候,MessageHandler.Whole的实现应该用于整个消息到达通知。

下面的代码片断会监听进来的文件消息，并将文本信息转换为大小版本后发回给其它端点：

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非常强大，因为它允许发送任或接收任何对象作为WebSocket消息.

基本上，有三种不同类型的消息:

• 基于文本的消息
• 二进制消息
• Pong 消息,它是WebSocket连接自身

当使用interface-driven模式,每个session最多只能为这三个不同类型的消息注册一个MessageHandler.

当使用annotation-driven模式,针对不同类型的消息，只允许出现一个@onMessage 注解方法. 在注解方法中，消息内容中允许的参数依赖于消息类型。

Javadoc for the @OnMessage annotation 明确指定了消息类型上允许出现的消息参数:

• "如果方法用于处理文本消息: 
  
  
  • String 用于接收整个消息
  • Java 原型或等价的类用于接收整个消息并将其转换为此类型
  • String 和 boolean 对用于部分接收消息
  • Reader 用于以阻塞流的方式接收整个消息
  • 端点的任何对象参数存在文本解码器 (Decoder.Text 或 Decoder.TextStream).
• 如果方法用于处理二进制消息: 
  
  
  • byte[] 或 ByteBuffer 用于接收整个消息
  • byte[] 和 boolean 对, 或者 ByteBuffer 和boolean对用于部分接收消息
  • InputStream 用于按阻塞流的方式接收整个消息
  • 端点的任何对象参数存在二进制解码器(Decoder.Binary or Decoder.BinaryStream).
• 如果方法是用于处理pong消息: 
  
  
  • PongMessage 用于处理pong消息"

任何Java对象使用编码器都可以编码为基于文本或二进制的消息.这种基于文本或二进制的消息将转输到其它端点，在其它端点，它可以解码成Java对象－或者被另外的WebSocket 包解释. 

通常情况下，XML或JSON用于来传送WebSocket消息, 编码/解码然后会将Java对象编组成XML或JSON并在另一端解码为Java对象.

encoder是以javax.websocket.Encoder 接口的实现来定义,decoder是以javax.websocket.Decoder 接口的实现来定义的. 

有时，端点实例必须知道encoders和decoders是什么.使用annotation-driven方式, 可向@ClientEndpoint 和 @ServerEndpoint l注解中的encode和decoder元素传递 encoders和decoders的列表。

Listing 1 中的代码展示了如何注册一个 MessageEncoder 类(它定义了MyJavaObject实例到文本消息的转换). MessageDecoder 是以相反的转换来注册的.

@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 接口有多个子接口:

• Encoder.Text 用于将Java对象转成文本消息
• Encoder.TextStream 用于将Java对象添加到字符流中
• Encoder.Binary 用于将Java对象转换成二进制消息
• Encoder.BinaryStream 用于将Java对象添加到二进制流中

类似地,Decoder 接口有四个子接口:

• Decoder.Text 用于将文本消息转换成Java对象
• Decoder.TextStream 用于从字符流中读取Java对象
• Decoder.Binary 用于将二进制消息转换成Java对象
• Decoder.BinaryStream 用于从二进制流中读取Java对象

结论

WebSocket Java API为Java开发者提供了标准API来集成IETF WebSocket标准.通过这样做，Web 客户端或本地客户端可使用任何WebSocket实现来轻易地与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