Java代码

1. STAT 1:chunk_size 80  
2. STAT 1:chunks_per_page 13107  
3. STAT 1:total_pages 1  
4. STAT 1:total_chunks 13107  
5. STAT 1:used_chunks 13107  
6. STAT 1:free_chunks 0  
7. STAT 1:free_chunks_end 13107  
8. STAT 2:chunk_size 100  
9. STAT 2:chunks_per_page 10485  
10. STAT 2:total_pages 1  
11. STAT 2:total_chunks 10485  
12. STAT 2:used_chunks 10485  
13. STAT 2:free_chunks 0  
14. STAT 2:free_chunks_end 10485  
15. STAT 3:chunk_size 128  
16. STAT 3:chunks_per_page 8192  
17. STAT 3:total_pages 1  
18. STAT 3:total_chunks 8192  
19. STAT 3:used_chunks 8192  
20. STAT 3:free_chunks 0  
21. STAT 3:free_chunks_end 8192  

STAT 1:chunk_size 80
STAT 1:chunks_per_page 13107
STAT 1:total_pages 1
STAT 1:total_chunks 13107
STAT 1:used_chunks 13107
STAT 1:free_chunks 0
STAT 1:free_chunks_end 13107
STAT 2:chunk_size 100
STAT 2:chunks_per_page 10485
STAT 2:total_pages 1
STAT 2:total_chunks 10485
STAT 2:used_chunks 10485
STAT 2:free_chunks 0
STAT 2:free_chunks_end 10485
STAT 3:chunk_size 128
STAT 3:chunks_per_page 8192
STAT 3:total_pages 1
STAT 3:total_chunks 8192
STAT 3:used_chunks 8192
STAT 3:free_chunks 0
STAT 3:free_chunks_end 8192

Java代码

1. STAT pid 2232  
2. STAT uptime 1348  
3. STAT time 1218120955  
4. STAT version 1.2.1  
5. STAT pointer_size 32  
6. STAT curr_items 0  
7. STAT total_items 0  
8. STAT bytes 0  
9. STAT curr_connections 1  
10. STAT total_connections 3  
11. STAT connection_structures 2  
12. STAT cmd_get 0  
13. STAT cmd_set 0  
14. STAT get_hits 0  
15. STAT get_misses 0  
16. STAT bytes_read 26  
17. STAT bytes_written 16655  
18. STAT limit_maxbytes 104857600  

STAT pid 2232
STAT uptime 1348
STAT time 1218120955
STAT version 1.2.1
STAT pointer_size 32
STAT curr_items 0
STAT total_items 0
STAT bytes 0
STAT curr_connections 1
STAT total_connections 3
STAT connection_structures 2
STAT cmd_get 0
STAT cmd_set 0
STAT get_hits 0
STAT get_misses 0
STAT bytes_read 26
STAT bytes_written 16655
STAT limit_maxbytes 104857600

综述

       Rmi自从JDK1.1就已经出现了。而对于为什么在JAVA的世界里需要一个这样 思想理念就需要看下：RMI问世由来。其实真正在国内使用到它的比较少，不过在前些年比较火的EJB就是在它的基础上进一步深化的。从本质上来讲RMI的兴起正是为了设计分布式的客户、服务器结构需求而应运而生的，而它的这种B/S结构思想能否和我们通常的JAVA编程更加贴切呢？言外之意就是能否让这种分布式的状态做到更加透明，作为开发人员只需要按照往常一样开发JAVA应用程序一样来开发分布式的结构。那现在的问题是如何来划平这个鸿沟呢？首先我们来分析下在JAVA世界里它的一些特点因素：

l         JAVA使用垃圾收集确定对象的生命周期。

l         JAVA使用异常处理来报告运行期间的错误。这里就要和我们网络通讯中的异常相联系起来了。在B/S结构的网络体系中我们的这种错误性是非常常见的。

l         JAVA编写的对象通过调用方法来调用。由于网络通讯把我们的客户与服务器之间阻隔开了。但是代理的一种方式可以很好的提供一种这样的假象，让开发人员或者使用者都感觉是在本地调用。

l         JAVA允许一种高级的使用类加载器（CLassLoader）机制提供系统类路径中没有的类。这话什么意思？

主要特点

上面说到了分布式的方式和我们的JAVA中如何更好的划平这个鸿沟，需要具备的特质。

那这里我们来看看我们所谓的RMI到底跟我们普通的JAVA（或者说JavaBean）存在一些什么样的差异：

l         RMI远程异常（Remote Exception）：在上面我们也提到了一个网络通讯难免有一些无论是软件级别的还是硬件级别的异常现象，有时候这些异常或许是一种无法预知的结果。让我们开发人缘如何来回溯这种异常信息，这个是我们开发人员要关心的。因此在调用远程对象的方法中我们必须在远程接口中（接口是一种规范的标准行为）所以在调用的这个方法体上需要签名注明：java.rmi,RemoteException.。这也就注明了此方法是需要调用远程对象的。

l         值传递 ：当把对象作为参数传递给一个普通的JAVA对象方法调用时，只是传递该对象的引用。请注意这里谈到的是对象的“引用”一词，如果在修改该参数的时候，是直接修改原始对象。它并不是所谓的一个对象的备份或者说拷贝（说白了就是在本JVM内存中的对象）。但是如果说使用的是RMI对象，则完全是拷贝的。这与普通对象有着鲜明的对比。也正是由于这种拷贝的资源消耗造就了下面要说到的性能缺失了。

l         调用开销：凡是经过网络通讯理论上来说都是一种资源的消耗。它需要通过编组与反编组方式不断解析类对象。而且RMI本身也是一种需要返回值的一个过程定义。

l         安全性：一谈到网络通讯势必会说到如何保证安全的进行。

概念定义

在开始进行原理梳理之前我们需要定义清楚几个名词。对于这些名词的理解影响到后的深入进行。

1.         Stub（存根，有些书上也翻译成：桩基在EJB的相关书籍中尤为体现这个意思）：

这里举例说明这个概念起（或许不够恰当）。例如大家因公出差后，都有存在一些报销的发票或者说小票。对于你当前手头所拿到的发票并不是一个唯一的，它同时还在你发生消费的地点有一个复印件，而这个复印件就是所谓的存根。但是这个存根上并没有很多明细的描述，只是有一个大概的金额定义。它把很多的细节费用都忽略了。所以这个也是我们说的存根定义。而在我们RMI的存根定义就是使用了这样一个理解：在与远程发生通讯调用时，把通讯调用的所有细节都通过对象的封装形式给隐藏在后端。这本身就符合OOAD的意思理念。而暴露出来的就是我们的接口方式，而这种接口方式又和服务器的对象具有相同的接口（这里就和我们前面举例说的报销单据联系上了，报销单据的存根不知道会有一个什么形式发生具体问题，而你手执的发票具体就需要到贵公司去报销费用，而这里的公司财务处就是所谓的服务器端，它才是真正干实质性问题的。）因此作为开发人员只需要把精力集中在业务问题的解决上，而不需要考虑复杂的分布式计算。所有这些问题都交给RMI去一一处理。

2.         Skeleton(一些书翻译叫骨架，也叫结构体)：它的内部就是真正封装了一个类的形成调用体现机制。包括我们熟知的ServerSocket创建、接受、监听、处理等。

3.         Mashalling(编组)：在内存中的对象转换成字节流，以便能够通过网络连接传输。

4.         Unmashalling(反编组)：在内存中把字节流转换成对象，以便本地化调用。

5.         Serialization(序列化)：编组中使用到的技术叫序列化。

6.         Deserializationg(反序列化)：反编组中使用到的技术叫反序列化。

客户端

       既然我们知道stub主要是以接口的方式来暴露体现，而stub主要 也是以代理的方式来具体实施。那在RMI中的这种接口有哪些特性呢？（Remote Interface）

1)        必须扩展（extends）java.rmi.Remote接口，因为远程接口并不包含任何一个方法，而是作为一个标记出现，它就是需要告诉JVM在RunTime的时候哪些是常规对象，哪些属于远程对象。通过这种标识的定义能让JVM了解类中哪些方法需要编组，通过了编组的方式才能通过网络序列化的调用；

2)        接口必须为public（公共），它的好处不言而喻的——能够方便的让所有人员来调用。

3)        接口方法还需要以异常抛出（例如：RemoteException），至于它的用处我们在前面也提到这里就不再复述；

4)        在调用一个远程对象期间（运行期间），方法的参数和返回值都要必须是可序列化的。至于为什么需要这么做？这里的缘由不用多说大家也应该清楚了解。

服务端

       既然我们知道stub所做的事情是一个简单的代理转发动作，那我们真正要做的对象就在服务端来做了。对于使用简单的RMI我们直接去指定，但是往往一旦使用了RMI对象就存在非常多的远程方法调用，这个时候服务器端对于这么多的调用如何来判别或者说识别呢？这里就要说到的是对于RMI实现它会创建一个标识符，以便以后的stub可以调用转发给服务器对象使用了，而这种方式我们通常叫服务器RMI的注册机制。言外之意就是让服务器端的对象注册在RMI机制中，然后可以导出让今后的stub按需来调用。那它又是如何做到这种方式的呢？对于RMI来说有两种方式可以达到这种效果：

a)         直接使用UnicastRemoteObject的静态方法：exportObject；

b)        继承UnicastRemoteObject类则缺省的构造函数exportObject。

现在大家又会问他们之间又有什么区别呢？我该使用哪种方式来做呢，这不是很难做抉择吗？从一般应用场景来说区别并不是很大，但是，这里说了“但是”哦，呵呵。大家知道继承的方式是把父类所具备的所有特质都可以完好无损的继承到子类中而对于类的总老大：Object来说里面有：equals()、hashCode()、toString()等方法。这是个什么概念呢？意思就是说如果对于本地化的调用，他们两个的方法（a,b）基本区别不是很大。但是我们这里强调的RMI如果是一种分布式的特定场景，具备使用哈希表这种特性就显得尤为重要了。

刚才说了服务端采用什么方法行为导出对象的。那现在导出后的对象又对应会发生什么情况呢？

首先被导出的对象被分配一个标识符，这个标识符被保存为：java.rmi.server.ObjID对象中并被放到一个对象列表中或者一个映射中。而这里的ID是一个关键字，而远程对象则是它的一个值（说到这大家有没有觉得它原理非常像HashMap的特质呢？没错，其实就是使用了它的特性），这样它就可以很好的和前面创建的stub沟通。如果调用了静态方法UnicastRemoteObject.export(Remote …)，RMI就会选择任意一个端口号，但这只是第一调用发生在随后的exportObject每次调用都把远程对象导出到该远程对象第一被导出时使用的端口号。这样就不会产生混乱，会把先前一一导出的对象全部放入到列表中。当然如果采用的是指定端口的，则按照对应显示的调用方式使用。这里稍作强调的是一个端口可以导出任意数目的对象。

       多数网络编程库中（以JAVA为主来说明），在JAVA平台中一样的提供了这些元素。而作为面向连接协议来说使用的是套接字（Socket）进行了更进一步的抽象描述。一般我们在JAVA的网络编程中都觉得在使用套接字这块相对方便，它不需要你去更多的了解操作系统的细节以及硬件的传递处理方式。TCP/IP的所有细节之处都得到了套接字的封装使用，让程序员关注到业务层面的处理。

       对象是一种抽象思维物质，对于计算机来说它只对数字电路的存储方式能够加以识别而且在网络传输当中也是一种信号量，而这一切只有使用字节流方式传输才是真正需要做到的。所以在本地主机与远程服务器的通讯传输就在对象与字节流之间不断相互转化才是我们真正需要的人性物质与机器所需要的。（有点墨迹了，切入整体）总体来说就是需要两种方式来认定这种传输行为：编组（Marshalling）与反编组（Unmarshalling）。而这一切的手段方式才是通过：序列化（Serialiazable）与反序列化的方式不断完成。如下图所示：

图：对象到字节再到对象的转换

       对于数据的传输本质就是上图说明的。那我们一般是如何使用套接字来构造我们这一行为呢？对于这里强调的主要是一种大致方法说明，所以只能以部分代码来说明客户端怎么来发送这个请求。

而作为服务器的接收方则把以上数据做一个逆转相反处理就可以。即服务器需要读取发送过来的对象数据，最终得到结果。现在假设还是一个甚至更多这样的对象处理，我们又要处理和以上代码差不多的过程。好，到这里我们可曾想到难道没有一种办法把这些过多的重复过程做一个通用的方式来提供吗？我如果不想去做这些繁杂的对象处理可以吗？比如，我想直接得到：

这样就能让我们把底层的那些庞杂数据转换能够透明封装起来呢？既然这个问题一经提出，那就意味着肯定有很多类似的需求。技术永远都是在需求的提出应运而生的。上面提出的需求就是我们要讨论的，既然我们想把一些套接字的重复处理过程来个封装清理，那需要面对的问题是什么呢？

1.      能够把所有的相同处理过程全部都移入到服务端呢？

2.      对于客户端来说能否只预留接口行为呢？

3.      把过多的复杂处理过程完善的做个封装？

4.      如果以上过程能够形成，那客户端又是如何办到可以连接到服务器端的组件行为呢？

既然能够把遇到的问题提出然后总结出来也就意味着我们需要去解决它。不知道是否还

记得设计模式中有一个叫：代理模式？没错，就是这个代理模式开始我们的描述。代理是一个实现给定接口的对象，但是不直接去执行代码结果，而是代表其他一些对象执行实际计算的对象。怎么理解这个话呢？举例说，如今很多城市都有火车票或者飞机票的代售点，这里的代售点其实就是采用了一种代理机制。我们想买某天的火车或者飞机票有时候并不需要到火车站或者飞机票的总点去购买票，而是找一个你最近的代售点去购买。代售点就是起到一个中间桥梁的作用，至于买票人员无需关心他们如何去订购，这些具体的动作都由他们内部去处理，你只关心最终是否有你需要的票就行。知道这个原理接下来就好理解很多了，我们最好以类图的方式来说明这个代理的机制，如图所示：

    到这里如果还觉得抽象，没关系接下来我以更加贴切的实例来结合类图的方式给出对应的参照说明。假如我们把上面的proxy模式再做个深入的探讨剖析（结合上面说的客户端发送参数作为请求和提出的问题综述）。大家都知道一个接口是能够在安全甚至在扩展上能够帮助我们非常大的功能。作为客户端最为希望的就是只关心我们需要的参数（或者变量）、返回值，而它如何而来，做了哪些具体工作这些都不是客户端关心的。Ok,现在结合我们说的接口方式，确实可以解决这个问题（接口的简单化，没有具体实现），但是你可能会问：

1.      既然接口如此简单，那参数又是如何传递过去的呢？

2.      服务端又如何知道我要的是什么呢？

带着问题我们来解决这个问题，当然也是大家所关心的问题了。现在开始要对于上面的proxy模式做个深入剖析了。我们先来看一个proxy模式演变的过程的图示：

图：RMI核心结构

    我们可以从图示看出从传统的proxy模式变化到一个变化的结构有什么不同呢？对于先前我们提出的两个问题就可以很好的做出解释了：

n         既然接口如此简单，那参数又是如何传递过去的呢？

A:既然是对客户端只开接口暴露，那么我们是就需要一个后台的socket来传输接口中已经定义好的参数，通过参数的编组（序列化）方式请求到远程服务上去响应处理。这当中要求定义到对方服务的服务名称和端口号。（这里也就是我们最先提到的那段代码了）

n         服务端又如何知道我要的是什么呢？

A:ok,既然客户端是通过socket来发送数据，那势必一定需要ServerSocket来做这个响应的接收处理了。问题是传过来的参数如何与我们的业务实现类关联上呢？所以这个也就是skeleton的职责所在了，在skeleton的封装处理中（启动中就把响应实现类给嵌入，聚合实现类），然后通过类转换处理和匹配处理来得到需要响应的结果了。

    本来说到这想大概有个收尾，但是总觉得还没有把一些问题说透彻。索性想再深入写写。
    从套接字衍生到RMI代码思路

    对于HashMap主要以键值(key-value)的方式来体现，笼统的说就是采用key值的哈希算法来，外加取余最终获取索引，而这个索引可以认定是一种地址，既而把相应的value存储在地址指向内容中。这样说或许比较概念化，也可能复述不够清楚，来看列式更加清晰：

其实最终就是这两个式子决定了值得存储位置。但是以上两个表达式还有欠缺。为什么这么说？例如在key.hashCode()后可能存在是一个负整数，你会问：是啊，那这个时候怎么办呢？所以在这里就需要进一步加强改造式子2了，修改后的：

到这里又迷惑了，为什么上面是这样的呢？对于先前我们谈到在hash有可能产生负数的情况，这里我们使用当前的hash做一个“与”操作，在这里需要和int最大的值相“与”。这样的话就可以保证数据的统一性，把有符号的数值给“与”掉。而一般这里我们把二进制的数值转换成16进制的就变成了：Ox7FFFFFFF。（注：与操作的方式为，不同为0，相同为1）。而对于hashCode()的方法一般有：

说道这里大家可能会说，到这里算完事了吧。但是你可曾想到如果数据都采用上面的方式，最终得到的可能index会相同怎么办呢？如果你想到的话，那恭喜你!又增进一步了，这里就是要说到一个名词：冲突率。是的就是前面说道的一旦index有相同怎么办？数据又该如何存放呢，而且这个在数据量非常庞大的时候这个基率更大。这里按照算法需要明确的一点：每个键（key）被散列分布到任何一个数组索引的可能性相同，而且不取决于其它键分布的位置。这句话怎么理解呢？从概率论的角度，也就是说如果key的个数达到一个极限，每个key分布的机率都是均等的。更进一步就是：即便key1不等于key2也还是可能key1.hashCode()=key2.hashCode()。

对于早期的解决冲突的方法有折叠法（folding)，例如我们在做系统的时候有时候会采用部门编号附加到某个单据标号后，这里比如产生一个9～11位的编码。通过对半折叠做。

现在的策略有：

1.       键式散列 

2.       开放地址法

在了解这两个策略前，我们先定义清楚几个名词解释：

清晰了这几个定义，我们再来看具体的解决方式

键式散列：

我们直接看一个实例，这样就更加清晰它的工作方式，从而避免文字定义。我们这里还是来举一个图书编号的例子，下面比如有这样一些编号：

                         78938-0000

                         45678-0001

                         72678-0002

                         24678-0001

                         16678-0001

                         98678-0003

                         85678-0002

                         45232-0004

步骤：

1.       把编号作为key,即：int hash=key.hashCode();

2.       int index=hash%表大小；

3.       逐步按顺序插入对象中

现在问题出现了：对于编号通过散列算法后很可能产生相同的索引值，意味着存在冲突。

解释上面的操作：如果对于key.hashCode()产生了冲突（比如途中对于插入24678-0001对于通过哈希算法后可能产生的index或许也是501），既而把相应的前驱有相同的index的对象指向当前引用。这也就是大家认定的单链表方式。以此类推…

而这里存在冲突对象的元素放在Entry对象中，Entry具有以下一些属性：

int hash;

Object key;

Entry next;

对于Entry对象就可以直接追溯到链表数据结构体中查阅。

开放地址法：

1.         线性地址探测法：

如何理解这个概念呢，一句话：就是通过算法规则在对象地址N+1中查阅找到为NULL的索引内容。

处理方式：如果index索引与当前的index有冲突，即把当前的索引index+1。如果在index+1已经存在占位现象（index+1的内容不为NULL）试图接着index+2执行。。。直到找到索引为内容为NULL的为止。这种处理方式也叫：线性地址探测法(offset-of-1)

如果采用线性地址探测法会带来一个效率的不良影响。现在我们来分析这种方式会带来哪些不良因素。大家试想下如果一个非常庞大的数据存储在Map中，假如在某些记录集中有一些数据非常相似（他们产生的索引在内存的某个块中非常的密集），也就是说他们产生的索引地址是一个连续数值，而造成数据成块现象。另一个致命的问题就是在数据删除后，如果再次查询可能无法定到下一个连续数字，这个又是一个什么概念呢？例如以下图片就很好的说明开发地址散列如何把数据按照算法插入到对象中：

对于上图的注释步骤说明：

从数据“78938-0000”开始通过哈希算法按顺序依次插入到对象中，例如78938-0000通过换

算得到索引为0，当前所指内容为NULL所以直接插入；45678-0001同样通过换算得到索引为地址501所指内容，当前内容为NULL所以也可以插入；72678-0002得到索引502所指内容，当前内容为NULL也可以插入；请注意当24678-0001得到索引也为501，当前地址所指内容为45678-0001。即表示当前数据存在冲突，则直接对地址501+1=502所指向内容为72678-0002不为NULL也不允许插入，再次对索引502+1=503所指内容为NULL允许插入。。。依次类推只要对于索引存在冲突现象，则逐次下移位知道索引地址所指为NULL；如果索引不冲突则还是按照算法放入内容。对于这样的对象是一种插入方式，接下来就是我们的删除(remove)方法了。按照常理对于删除，方式基本区别不大。但是现在问题又出现了，如果删除的某个数据是一个存在冲突索引的内容，带来后续的问题又会接踵而来。那是什么问题呢？我们还是同样来看看图示的描述，对于图-2中如果删除(remove)数据24678-0001的方法如下图所示：

对于我们会想当然的觉得只要把指向数据置为NULL就可以,这样的做法对于删除来说当然是没有问题的。如果再次定位检索数据16678-0001不会成功，因为这个时候以前的链路已经堵上了，但是需要检索的数据事实上又存在。那我们如何来解决这个问题呢？对于JDK中的Entry类中的方法存在一个：boolean markedForRemoval;它就是一个典型的删除标志位，对于对象中如果需要删除时，我们只是对于它做一个“软删除”即置一个标志位为true就可以。而插入时，默认状态为false就可以。这样的话就变成以下图所示：

通过以上方式更好的解决冲突地址删除数据无法检索其他链路数据问题了。

2.         双散列（余商法）

在了解开放地址散列的时候我们一直在说解决方法，但是大家都知道一个数据结构的完善更多的是需要高效的算法。这当中我们却没有涉及到。接下来我们就来看看在开放地址散列中它存在的一些不足以及如何改善这样的方法，既而达到无论是在方法的解决上还是在算法的复杂度上更加达到高效的方案。

在图2-1中类似这样一些数据插入进对象，存在冲突采用不断移位加一的方式，直到找到不为NULL内容的索引地址。也正是由于这样一种可能加大了时间上的变慢。大家是否注意到像图这样一些数据目前呈现出一种连续索引的插入，而且是一种成块是的数据。如果数据量非常的庞大，或许这种可能性更大。尽管它解决了冲突，但是对于数据检索的时间度来说，我们是不敢想象的。所有分布到同一个索引index上的key保持相同的路径：index,index+1,index+2…依此类推。更加糟糕的是索引键值的检索需要从索引开始查找。正是这样的原因，对于线性探索法我们需要更进一步的改进。而刚才所描述这种成块出现的数据也就定义成：簇。而这样一种现象称之为：主簇现象。

（主簇：就是冲突处理允许簇加速增长时出现的现象）而开放式地址冲突也是允许主簇现象产生的。那我们如何来避免这种主簇现象呢？这个方式就是我们要来说明的：双散列解决冲突法了。主要的方式为：

u       int hash=key.hasCode();

u       int index=(hash&Ox7FFFFFFF)%table.length;

u       按照以上方式得到索引存在冲突，则开始对当前索引移位，而移位方式为：

        offset=(hash&Ox7FFFFFFF)/table.length;

u       如果第一次移位还存在同样的冲突，则继续：当前冲突索引位置（索引号+余数）%表.length

u       如果存在的余数恰好是表的倍数，则作偏移位置为一下移，依此类推

这样双散列冲突处理就避免了主簇现象。至于HashSet的原理基本和它是一致的，这里不再复述。在这里其实还是主要说了一些简单的解决方式，而且都是在一些具体参数满足条件下的说明，像一旦数据超过初始值该需要rehash，加载因子一旦大于1.0是何种情况等等。还有很多问题都可以值得我们更加进一步讨论的，比如：在java.util.HashMap中的加载因子为什么会是0.75，而它默认的初始大小为什么又是16等等这些问题都还值得说明。要说明这些问题可能又需要更加详尽的说明清楚。