前言
学习任何一个稍有难度的技术，要对其有充分理性的分析，之后果断做出决定---->也就是人们常说的“多谋善断"；本系列虽然涉及的是socket相关的知识，但学习之前，更想和广大程序员分享的是一种心境
：学习是一个循序渐进的过程，心态应该随时调节，保持戒骄戒躁的状态。比如最近在看网易公开课MIT《算法导论》，老师提到，学习算法之前要计算机数学+离散数学+概率论等课程的知识，所以一直学不好算法的程序员不妨从基础入手，这都是中国式教育惹的祸啊！（此处省略一万字......）
原文地址：Building a Java chart server[1]
项目源码：Socket_Chat
目录
正文
读写循环（客户端）
在服务端，我们已经有了读写循环，还需要在客户端创建。目的是一样的：读取传入的信息，处理它，作为响应可能会写入一些特征返回到服务端。然后一直重复着做这些事情。
这是客户端看起来的样子：
// 后台线程运行：从其他窗口显示信息 public void run() { try { // 接受信息一个到一个，一直循环 while (true) { // 获取下一条信息 String message = din.readUTF(); // 打印在文本窗口中 ta.append( message+"\n" ); } } catch( IOException ie ) { System.out.println( ie ); } }相当简单。每个传入的信息会显示在窗口上，然后循环等待下一条信息的传入。
—————————————————————————————————————————————————————————————————————————
局限
现在，我们有一个完整，尽管很简约，多线程的聊天室系统。怎么可能出错呢？
正如我们在介绍中提到的一样，没有服务端框架对于所有任务是平等的。知道这种方法的局限性是很重要的，你会决定是否你会应用这些想法在你自己的项目中去。
—————————————————————————————————————————————————————————————————————————
简化连接模型
我们创建的聊天室系统仅仅是一个聊天室。记住每个信息会传入服务器然后发送给每个客户端。这个是不满足现实世界的要求的，不仅是由于显示时间的用户想要单独的聊天室，而且带宽的极大浪费。
当然，在我们的模型中允许用户选择一个聊天室，然后根据房间名字连接每个信息，这样信息只会发送给相同房间里面的用户。
然而，我们没有为这个选择设置地方。我们的服务端线程对象简单地调用我们服务端对象方法sendToAll()。在真实世界里，服务端线程会分发信息给真实的分发系统。
—————————————————————————————————————————————————————————————————————————
过多的线程
在一些Java实现中，为每个用户创建显示不是一个好主意，因为有过多的线程 -- 即使它们全部休眠 -- 也可以让系统死掉。
这是你需要测试的地方，因为没有尝试就预料线程性能是不可能的。而且也证明了Java实现不能处理它，这个解决方案很危险。
这种情况下，你不得不用一种小、但是会从sockets读取一定数量的线程，你不得不使用不阻塞的线程，也就是意味着你不得不使用轮训，那就意味着……等等。这是一个大麻烦，如果你的JVM不能处理需多线程，打电话给你的供应商抱怨他吧！
—————————————————————————————————————————————————————————————————————————
内部同步
在Server.java中注释的代码提到一些线程同步经常用于适当保持活跃连接列表。这种同步真的可以影响性能。
如果同步证明是一个瓶颈，那么你可以试试下面的事情：
- 修改removeConnection()，简化移除链接的记录，获取在另一个列表中。然后遍历中或遍历后，在sendToAll()中真正移除的动作。
- 使用不止一个线程写入sendToAll().
—————————————————————————————————————————————————————————————————————————
结束语
本编教程涉及了Java语言中大量细节使用在多线程的构造函数中，面向对象的服务端。你已经学会怎样一次处理多个客户端，而且你也知道了7大功能点组成了这样的服务器。
参考文献
[2]. Java sockets 101以及中文系列 JAVA套接字（Socket）101
[3]. Java socket通信基本原理介绍