我们现在已经拥有的 MultithreadedServer
每当有客户机申请一个连接时都在一个新 Thread
中创建一个新 ConnectionHandler
。这意味着可能有一捆 Thread
“躺”在我们周围。而且创建 Thread
的系统开销并不是微不足道的。如果性能成为了问题(也请不要事到临头才意识到它),更高效地处理我们的服务器是件好事。那么,我们如何更高效地管理服务器端呢?我们可以维护一个进入的连接池,一定数量的ConnectionHandler
将为它提供服务。这种设计能带来以下好处:
ConnectionHandler
Thread
一次。 幸运的是,跟在我们的多线程示例中一样,往代码中添加“池”不需要来一个大改动。事实上,应用程序的客户机端根本就不受影响。在服务器端,我们在服务器启动时创建一定数量的 ConnectionHandler
,我们把进入的连接放入“池”中并让 ConnectionHandler
打理剩下的事情。这种设计中有很多我们不打算讨论的可能存在的技巧。例如,我们可以通过限定允许在“池”中建立的连接的数目来拒绝客户机。
请注意:我们将不会再次讨论 acceptConnections()
。这个方法跟前面示例中的完全一样。它无限循环地调用 ServerSocket
上的 accept()
并把连接传递到 handleConnection()
。
2. 创建 PooledRemoteFileServer 类
这里是 PooledRemoteFileServer
类的结构:
请注意一下您现在应该熟悉了的 import
语句。我们给类以下实例变量以保存:
ServerSocket
类的构造器用的参数是侦听端口和连接的最大数目
我们的类有一个 main()
方法和三个其它方法。稍后我们将探究这些方法的细节。现在只须知道 setUpHandlers()
创建数目为 maxConnections
的大量 PooledConnectionHandler
,而其它两个方法则与我们前面已经看到的相似:acceptConnections()
在 ServerSocket
上侦听传入的客户机连接,而 handleConnection
则在客户机连接一旦被建立后就实际处理它。
3. 实现 main()
这里我们实现需作改动的 main()
方法,该方法将创建能够处理给定数目的客户机连接的 PooledRemoteFileServer
,并告诉它接受连接:
我们的 main()
方法很简单。我们实例化一个新的 PooledRemoteFileServer
,它将通过调用 setUpHandlers()
来建立三个PooledConnectionHandler
。一旦服务器就绪,我们就告诉它 acceptConnections()
。
4. 建立连接处理程序
setUpHandlers()
方法创建 maxConnections
(例如 3)个 PooledConnectionHandler
并在新 Thread
中激活它们。用实现了 Runnable
的对象来创建 Thread
使我们可以在 Thread
调用 start()
并且可以期望在 Runnable
上调用了 run()
。换句话说,我们的 PooledConnectionHandler
将等着处理进入的连接,每个都在它自己的 Thread
中进行。我们在示例中只创建三个 Thread
,而且一旦服务器运行,这就不能被改变。
5. 处理连接
这里我们实现需作改动的 handleConnections()
方法,它将委派 PooledConnectionHandler
处理连接:
我们现在叫 PooledConnectionHandler
处理所有进入的连接(processRequest()
是一个静态方法)。
这里是 PooledConnectionHandler
类的结构:
这个助手类与 ConnectionHandler
非常相似,但它带有处理连接池的手段。该类有两个实例变量:
connection
是当前正在处理的 Socket
pool
的静态 LinkedList
保存需被处理的连接
6. 填充连接池
这里我们实现 PooledConnectionHandler
上的 processRequest()
方法,它将把传入请求添加到池中,并告诉其它正在等待的对象该池已经有一些内容:
理解这个方法要求有一点关于 Java 的关键字 synchronized
如何工作的背景知识。我们将简要讲述一下线程。
先来看一些定义:
因此,当对象 A 想使用对象 B 的 synchronized
方法 doSomething()
时,对象 A 必须首先尝试获取对象 B 的互斥锁。是的,这意味着当对象 A 拥有该互斥锁时,没有其它对象可以调用对象 B 上任何其它 synchronized
方法。
synchronized
块是个稍微有些不同的东西。您可以同步任何对象上的一个块,而不只是在本身的某个方法中含有该块的对象。在我们的示例中,processRequest()
方法包含有一个 pool
(请记住它是一个 LinkedList
,保存等待处理的连接池)的 synchronized
块。我们这样做的原因是确保没有别人能跟我们同时修改连接池。
既然我们已经保证了我们是唯一“涉水”池中的人,我们就可以把传入的 Socket
添加到 LinkedList
的尾端。一旦我们添加了新的连接,我们就用以下代码通知其它正在等待该池的 Thread
,池现在已经可用:
pool.notifyAll();
Object
的所有子类都继承这个 notifyAll()
方法。这个方法,连同我们下一屏将要讨论的 wait()
方法一起,就使一个 Thread
能够让另一个Thread
知道一些条件已经具备。这意味着该第二个 Thread
一定正在等待那些条件的满足。
7. 从池中获取连接
这里我们实现 PooledConnectionHandler
上需作改动的 run()
方法,它将在连接池上等待,并且池中一有连接就处理它:
回想一下在前一屏讲过的:一个 Thread
正在等待有人通知它连接池方面的条件已经满足了。在我们的示例中,请记住我们有三个PooledConnectionHandler
在等待使用池中的连接。每个 PooledConnectionHandler
都在它自已的 Thread
中运行,并通过调用 pool.wait()
产生阻塞。当我们的 processRequest()
在连接池上调用 notifyAll()
时,所有正在等待的 PooledConnectionHandler
都将得到“池已经可用”的通知。然后各自继续前行调用 pool.wait()
,并重新检查 while(pool.isEmpty())
循环条件。除了一个处理程序,其它池对所有处理程序都将是空的,因此,在调用 pool.wait()
时,除了一个处理程序,其它所有处理程序都将再次产生阻塞。恰巧碰上非空池的处理程序将跳出while(pool.isEmpty())
循环并攫取池中的第一个连接:
connection = (Socket) pool.remove(0);
处理程序一旦有一个连接可以使用,就调用 handleConnection()
处理它。
在我们的示例中,池中可能永远不会有多个连接,只是因为事情很快就被处理掉了。如果池中有一个以上连接,那么其它处理程序将不必等待新的连接被添加到池。当它们检查 pool.isEmpty()
条件时,将发现其值为假,然后就从池中攫取一个连接并处理它。
还有另一件事需注意。当 run()
拥有池的互斥锁时,processRequest()
如何能够把连接放到池中呢?答案是对池上的 wait()
的调用释放锁,而wait()
接着就在自己返回之前再次攫取该锁。这就使得池对象的其它同步代码可以获取该锁。
这里我们实现需做改动的 handleConnection()
方法,该方法将攫取连接的流,使用它们,并在任务完成之后清除它们:
跟在多线程服务器中不同,我们的 PooledConnectionHandler
有一个 handleConnection()
方法。这个方法的代码跟非池式的 ConnectionHandler
上的 run()
方法的代码完全一样。首先,我们把 OutputStream
和 InputStream
分别包装进(用 Socket
上的 getOutputStream()
和getInputStream()
)BufferedReader
和 PrintWriter
。然后我们逐行读目标文件,就象我们在多线程示例中做的那样。再一次,我们获取一些字节之后就把它们放到本地的 line
变量中,然后写出到客户机。完成读写操作之后,我们关闭 FileReader
和打开的流。
9. 总结一下带有连接池的服务器
我们的带有连接池的服务器研究完了。让我们回顾一下创建和使用“池版”服务器的步骤:
PooledConnectionHandler
)来处理池中的连接。PooledConnectionHandler
。 附:
PooledRemoteFileServer
的完整代码清单
PooledConnectionHandler
的完整代码清单
1. 介绍
我们到目前为止讨论过的示例已经涵盖了 Java 编程的套接字机制,但在“现实”的一些例子中如何使用它们呢?即便用了多线程和带有连接池,如此简单地使用套接字,在多数应用程序中仍然是不合适的。相反地,在构成您的问题域的模型的其它类中使用套接字可能是明智的。
最近我们在把一个应用程序从大型机/SNA 环境移植到 TCP/IP 环境时就是这样做的。该应用程序的工作是简化零售渠道(例如硬件商店)和金融机构之间的通信。我们的应用程序是中间人。同样地,它必须与一端的零售渠道和另一端的金融渠道通信。我们必须处理客户机通过套接字与服务器进行的交谈,我们还必须把域对象转换成套接字就绪的形式以进行传输。
我们不能在本教程中涵盖这个应用程序的所有细节,但我们将带您浏览一些高层概念。您可以据此对您自己的问题域做些推断。
2. 客户机端
在客户机端,我们系统中的主角是 Socket
、ClientSocketFacade
和 StreamAdapter
。客户机端的 UML 如下图所示:
我们创建了一个 ClientSocketFacade
,它是 Runnable
的并且拥有一个 Socket
实例。我们的应用程序可以用一个特定的主机 IP 地址和端口号来实例化一个 ClientSocketFacade
,并在一个新 Thread
中运行它。ClientSocketFacade
的 run()
方法调用 connect()
,connect()
惰性初始化一个Socket
。有了 Socket
实例,我们的 ClientSocketFacade
就调用自己的 receive()
,receive()
将造成阻塞直到服务器在 Socket
上发送数据。一旦服务器发送数据,我们的 ClientSocketFacade
就将醒来并处理传入的数据。数据的发送是直接的。我们的应用程序可以通过用一个 StreamObject
调用 send()
方法来简单地告诉它的 ClientSocketFacade
把数据发送到服务器。
上述讨论中唯一遗漏的一个是 StreamAdapter
。当应用程序告诉 ClientSocketFacade
发送数据时,该 Facade 将委派 StreamAdapter
的实例处理有关操作。ClientSocketFacade
委派 StreamAdapter
的同一个实例处理接收数据的操作。StreamAdapter
把消息加工成最终格式并将它放到 Socket
的OutputStream
上,并以逆过程处理从 Socket
的 InputStream
传入的消息。
例如,或许您的服务器需要知道发送中的消息的字节数。StreamAdapter
可以在发送之前计算消息的长度并将它附加在消息的前端。当服务器接收消息时,同样的 StreamAdapter
能够剥离长度信息并读取正确数量的字节以构建一个 StreamReadyObject
。
3. 服务器端
服务器端的情形差不多
我们把 ServerSocket
包装进 ServerSocketFacade
,ServerSocketFacade
是 Runnable
的并且拥有一个 ServerSocket
实例。我们的应用程序可以用一个特定的服务器端侦听端口和客户机连接的最大允许数目(缺省值是 50)来实例化一个 ServerSocketFacade
。应用程序然后在一个新 Thread
中运行 Facade 以隐藏 ServerSocket
的交互操作细节。
ServerSocketFacade
上的 run()
方法调用 acceptConnections()
,acceptConnections()
创建一个新的 ServerSocket
,并调用 ServerSocket
上的accept()
以造成阻塞直到有客户机请求一个连接。每当有客户机请求连接,我们的 ServerSocketFacade
就醒来并通过调用 handleSocket()
来把accept()
返回的新 Socket
传递给 SocketHandler
的实例。SocketHandler
的分内工作是处理从客户机到服务器的新通道。
4. 业务逻辑
一旦我们正确布置了这些 Socket
Facade,实现应用程序的业务逻辑就变得容易多了。我们的应用程序使用 ClientSocketFacade
的一个实例来在 Socket
上把数据发送到服务器并取回响应。应用程序负责把我们的域对象转换成 ClientSocketFacade
理解的格式并根据响应构建域对象。
5. 发送消息到服务器
下图显示我们的应用程序发送消息的 UML 交互作用图:
为简单起见,我们未显示 aClientSocketFacade
向它的 Socket
实例请求其 OutputStream
的交互作用(用 getOutputStream()
方法)。一旦我们有了一个 OutputStream
引用,我们就如图所示那样与它交互。请注意 ClientSocketFacade
对我们的应用程序隐藏了套接字交互作用的低级细节。我们的应用程序与 aClientSocketFacade
交互,而不与任何更低级类交互,这些类使把字节放到 Socket OutputStream
上更容易。
6. 接收来自服务器的消息
下图显示我们的应用程序接收消息的 UML 交互作用图:
请注意我们的应用程序在一个 Thread
中运行 aClientSocketFacade
。当 aClientSocketFacade
启动时,它告诉自己在自己的 Socket
实例的InputStream
上进行 receive()
。receive()
方法调用 InputStream
自身的 read(byte[])
。read([])
方法将造成阻塞直到它接收到数据,并把在InputStream
接收到的数据放到一个 byte 数组中。当数据到来时,aClientSocketFacade
用 aStreamAdapter
和 aDomainAdapter
构造(最终地)应用程序能够使用的域对象。接着它把该域对象传回给应用程序。再一次,我们的 ClientSocketFacade
对应用程序隐藏了更低级细节,从而简化了应用层。
总结
Java 语言简化了套接字在应用程序中的使用。它的基础实际上是 java.net
包中的 Socket
和 ServerSocket
类。一旦您理解了表象背后发生的情况,就能容易地使用这些类。在现实生活中使用套接字只是这样一件事,即通过贯彻优秀的 OO 设计原则来保护应用程序中各层间的封装。我们为您展示了一些有帮助的类。这些类的结构对我们的应用程序隐藏了 Socket
交互作用的低级细节 ― 使应用程序能只使用可插入的ClientSocketFacade
和 ServerSocketFacade
。在有些地方(在 Facade 内),您仍然必须管理稍显杂乱的字节细节,但您只须做一次就可以了。更好的是,您可以在将来的项目中重用这些低级别的助手类。