ForkJoinPool 是 Java SE 7 新功能“分叉/结合框架”的核心类，现在可能乏人问津，但我觉得它迟早会成为主流。分叉/结合框架是一个比较特殊的线程池框架，专用于需要将一个任务不断分解成子任务（分叉），再不断进行汇总得到最终结果（结合）的计算过程。比起传统的线程池类 ThreadPoolExecutor，ForkJoinPool 实现了工作窃取算法，使得空闲线程能够主动分担从别的线程分解出来的子任务，从而让所有的线程都尽可能处于饱满的工作状态，提高执行效率。

ForkJoinPool 提供了三类方法来调度子任务：

execute 系列

异步执行指定的任务。

invoke 和 invokeAll

执行指定的任务，等待完成，返回结果。

submit 系列

异步执行指定的任务并立即返回一个 Future 对象。

子任务由 ForkJoinTask 的实例来代表。它是一个抽象类，JDK 为我们提供了两个实现：RecursiveTask 和 RecursiveAction，分别用于需要和不需要返回计算结果的子任务。ForkJoinTask 提供了三个静态的 invokeAll 方法来调度子任务，注意只能在 ForkJoinPool 执行计算的过程中调用它们。

ForkJoinPool 和 ForkJoinTask 还提供了很多让人眼花缭乱的公共方法，其实它们大多数都是其内部实现去调用的，对于应用开发人员来说意义不大。

下面以统计 D 盘文件个数为例。这实际上是对一个文件树的遍历，我们需要递归地统计每个目录下的文件数量，最后汇总，非常适合用分叉/结合框架来处理：

// 处理单个目录的任务
public class CountingTask extends RecursiveTask<Integer> {
    private Path dir;

    public CountingTask(Path dir) {
        this.dir = dir;
    }

    @Override
    protected Integer compute() {
        int count = 0;
        List<CountingTask> subTasks = new ArrayList<>();

        // 读取目录 dir 的子路径。
        try (DirectoryStream<Path> ds = Files.newDirectoryStream(dir)) {
            for (Path subPath : ds) {
                if (Files.isDirectory(subPath, LinkOption.NOFOLLOW_LINKS)) {
                    // 对每个子目录都新建一个子任务。
                    subTasks.add(new CountingTask(subPath));
                } else {
                    // 遇到文件，则计数器增加 1。
                    count++;
                }
            }

            if (!subTasks.isEmpty()) {
                // 在当前的 ForkJoinPool 上调度所有的子任务。
                for (CountingTask subTask : invokeAll(subTasks)) {
                    count += subTask.join();
                }
            }
        } catch (IOException ex) {
            return 0;
        }
        return count;
    }
}

// 用一个 ForkJoinPool 实例调度“总任务”，然后敬请期待结果……
Integer count = new ForkJoinPool().invoke(new CountingTask(Paths.get("D:/")));
    

在我的笔记本上，经多次运行这段代码，耗费的时间稳定在 600 豪秒左右。普通线程池（Executors.newCachedThreadPool()）耗时 1100 毫秒左右，足见工作窃取的优势。

结束本文前，我们来围观一个最神奇的结果：单线程算法（使用 Files.walkFileTree(...)）比这两个都快，平均耗时 550 毫秒！这警告我们并非引入多线程就能优化性能，并须要先经过多次测试才能下结论。

前面已经看到，Socket 类的 getInputStream() 和 getOutStream() 方法分别获取套接字的输入流和输出流。输入流用来读取远端发送过来的数据，输出流则用来向远端发送数据。

输入流

使用套接字的输入流读取数据时，当前线程会进入阻塞状态，直到套接字收到一些数据为止（亦即套接字的接收缓冲区有可用数据）。该输入流的 available() 方法只是返回接收缓冲区的可用字节数量，不可能知道远端还要发送多少字节。使用输入流的时候，最好先将它包装为一个 BufferedInputStream，因为读取接收缓冲区将导致 JVM 和底层系统之间的切换，应当尽量减少切换次数以提高性能。BufferedInputStream 的缓冲区大小最好设为套接字接收缓冲区的大小。

如果直接调用输入流的 close() 方法来关闭它，则将导致套接字被关闭。对此，Socket 类提供了一个 shutdownInput() 方法来禁用输入流。调用该方法后，每次读操作都将返回 EOF，无法再读取远端发送的数据。对这个 EOF 的检测，不同的输入流包装体现出不同的结果，可能读到 -1 个字节，可能读到的字符串为 null，还可能收到一个 EOFException 等等。禁用输入流后，远端输出流的行为是平台相关的：

• 在 BSD 平台上，远端的发送的数据能正常接收，然后直接丢弃。远端无法知道本端的输入流已禁用。这和 JDK 文档描述的行为一致。
• 在 WINSOCK 平台上，远端发送数据将会导致“连接被重置”的错误。
• 在 Linux 平台上，远端发送的数据能继续接收，直到套接字输入缓冲区填满，之后远端再也无法发送数据（若使用阻塞模式则进入死锁）。

禁用输入流这种技术并不常用。

输出流

套接字的输出操作实际上仅仅将数据写到发送缓冲区内，当发送缓冲区填满且上次的发送成功后，由底层系统负责发送。如果发送缓冲区的剩余空间不够，当前线程就会阻塞。和输入流类似，最好将输出流包装为 BufferedOutputStream。

如果套接字的双发都使用 ObjectInputStream 和 ObjectOutputStream 来读写 Java 对象，则必须先创建 ObjectOutputStream，因为 ObjectInputStream 在构造的时候会试图读取对象头部，如果双发都先创建 ObjectInputStream，则会互相等待对方的输出，造成死锁：

// 创建的顺序不能颠倒！
ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());
ObjectInputStream in = new ObjectInputStream(socket.getInputStream());
    

类似于输入流，关闭输出流也导致关闭套接字，所以 Socket 类同样提供了一个 shutdownOutput() 来禁用输出流。禁用输出流后，已写入发送缓冲区的数据会正常发送，之后的任何写操作都会导致 IOException，且远端的输入流始终会读到 EOF。禁用输出流非常有用，例如套接字的双发都在发送完毕数据后禁用输入流，然后双方都会收到 EOF，从而知道数据已经全部交换完毕，可以安全关闭套接字。直接关闭套接字会同时关闭输入流和输出流，且断开连接，达不到这种效果。

使用流的阻塞套接字的优缺点

如果要使用流进行输入和输出，就只能用阻塞模式的套接字。这里总结一下阻塞套接字的优缺点。先看看优点：

1. 编程模型简单，非常适合初学者上手。
2. 以装饰器模式设计的 Java I/O 使得开发人员可以轻松地从 I/O 流读写任何类型的数据。

但在性能方面有致命的缺点：

1. 由于服务器套接字接受连接，以及套接字的读写都会阻塞，性能低下。
2. 如果不对 I/O 流手动进行缓冲，则可能造成一次只处理一个字节，性能低下。
3. 服务器套接字每次只能接受一个连接，导致 JVM 和底层系统之间频繁的调用切换，性能低下。

下一篇文章开始探讨使用基于 NIO 的套接字通道和缓冲区实现伸缩性更强的 TCP 套接字。

ServerSocket 类和 Socket 类都提供了多个公共构造方法。不同的构造方法不仅带的参数不同，所具有的意义也不一样。下面分别解析这两个类的实例初始化过程。

ServerSocket 实例的初始化

ServerSocket 类提供了四个构造器：

public ServerSocket(int port) throws IOException

public ServerSocket(int port, int backlog) throws IOException

public ServerSocket(int port, int backlog, InetAddress bindAddr) throws IOException

public ServerSocket() throws IOException

带参构造器用来创建已绑定的服务器套接字，也就是说构造成功后它就已经开始侦听指定的端口，且能够调用 accept() 方法来接受客户端连接。默认构造器则会创建未绑定的服务器套接字，构造成功后必须手动将其绑定到一个本地地址才能用，在绑定之前可以进行一些选项配置。

带参构造器

总的来说，带参构造器提供了三个参数：

port

指定该服务器套接字所要侦听的本地端口。如果为 0，则由系统自动分配一个端口号，这必须以另外的方式让客户端获取端口号。

backlog

这个名词目前还没有合适的译名。底层系统的 TCP 实现会维护一个连接队列，该队列缓存了已被 TCP 处理完毕，但还没有被服务器套接字接受的客户端连接。一旦某个连接被接受（通过调用 accept() 方法），它就会被从队列中移除。backlog 参数就用于指定队列的最大长度，默认值为 50，但这个值只是一个建议，底层系统可能根据需要自动调整。如果队列满了，则其行为是平台相关的：微软的 WINSOCK 会拒绝新的连接，其他实现则什么都不做。严格地说，微软没有遵守规范，破坏了游戏规则……

bindAddr

一台机器可能会有多个本地 IP 地址，例如同时使用多块网卡。使用其他两个带参构造器时，该参数为 null，服务器套接字会在所有的本地 IP 地址（0.0.0.0 或 ::0）上侦听。如果希望只侦听一个地址，则可使用该参数。

默认构造器

如果使用默认构造器，在绑定地址前，还可以做些配置。绑定操作由两个 bind 方法定义，参数类似于带参构造器。配置项包括以下方面（都必须在绑定前配置）：

设置是否重用本地地址

该选项由 setReuseAddress(boolean on) 方法配置，对应底层系统的 SO_REUSEADDR 套接字选项。JDK 没有定义该选项的默认值。如果该选项为 false，则在关闭 TCP 连接时，为了保证可靠性，该连接可能在关闭后的一段时间（大约两分钟）内保持超时状态（通常称为 TIME_WAIT 状态或 2MSL 等待状态），这段时间里无法将新建的服务器套接字绑定到同一个地址。在开发阶段，服务器可能不断重启，打开改选项会非常有用。

设置接收缓冲区大小

该选项由 setReceiveBufferSize(int size) 方法配置，对应底层系统的 SO_RCVBUF 套接字选项，单位是字节。《RFC 1323 - TCP Extensions for High Performance》将缓冲区大小定义为 64KB。该选项只是一个建议值，底层系统可能根据需要自行调整。

设置超时值

该选项由 setSoTimeout(int timeout) 方法配置，对应底层系统的 SO_TIMEOUT 套接字选项，单位是毫秒。默认值为 0。该选项影响 accept 方法的阻塞时间长度，如果超时将引发 SocketTimeoutException。如果设为 0，则表示永不超时。

设置性能首选项

性能首选项包括连接时间、延迟和带宽三个选项，由 setPerformancePreferences(int connectionTime, int latency, int bandwidth) 方法配置。这三个数值分别表示短连接时间、低延迟和高带宽的相对重要性，数值越大则越重要；其各自的绝对值没有意义。该方法的初衷是为了让 Java 能在用非 TCP/IP 实现的套接字环境下工作得更好，某些需要对网络进行调优的程序也可以将这三个首选项作为配置参数提供给用户。

Socket 实例的初始化

Socket 类提供了六个公共构造器（已过时的除外）：

public Socket(String host, int port) throws UnknownHostException, IOException

public Socket(InetAddress address, int port) throws IOException

public Socket(String host, int port, InetAddress localAddr, int localPort) throws IOException

public Socket(InetAddress address, int port, InetAddress localAddr, int localPort) throws IOException

public Socket()

public Socket(Proxy proxy)

前四个构造器创建已连接的客户端套接字，也就是说构造的时候就会去连接服务器。前两个构造器需要提供服务器的地址和端口作为参数，本地地址和端口由系统自动分配；后两个允许手动指定本地地址和端口，但极少使用。后两个构造器创建未连接的套接字，创建后需要调用 connect 方法手动连接，连接之前可以做一些配置。最后一个构造器接受一个代表代理服务其的 Proxy 对象，JDK 支持 HTTP 和 SOCKS（V4 或 V5）两种代理类型。

连接前的配置

在连接前，客户端套接字不仅像服务器套接字那样可以设置是否重用本地地址、缓冲区大小、超时值和性能首选项，还能够配置以下各项（都必须在连接前配置）：

设置是否保持活跃

该选项由 setKeepAlive(boolean on) 方法配置，对应底层系统的 SO_KEEPALIVE 套接字选项。默认值为 false。如果打开该选项，则套接字会定期自动发送保持活跃的探测性消息，类似于心跳检测。根据《RFC 1122 - Requirements for Internet Hosts》的规定，保持活跃机制只是 TCP 的一个可选功能，如果支持的话，默认必须为 false，而且这种机制默认在成功建立连接后，且连续两小时没有数据传输的情况下才会被激活。从另一方面来看，通过套接字的 I/O 操作完全可以知道连接是否还有效，所以该选项的实用价值不大。

设置是否收发带外数据

该选项由 setOOBInline(boolean on) 方法配置，对应底层系统的 SO_OOBINLINE 套接字选项。默认值为 off。带外数据（Out-of-band Data）也叫做紧急数据，表示数据很重要，需要使用不同于发送普通数据的一个专用通道来发送。打开该选项后，就可以调用 sendUrgentData(int data) 方法发送一个字节的紧急数据。JDK 对带外数据只提供了有限支持，紧急数据将会和普通数据一起被收到，并且无法自动区分。该选项对应用开发人员意义不大。

设置是否从容关闭连接

该选项由 setSoLinger(boolean on, int linger) 方法配置，对应底层系统的 SO_LINGER 套接字选项。默认为 false。该选项只会影响套接字的关闭，其中的 linger 参数表示超时时间，单位为秒。如果打开改选项：如果将 linger 设为 0，则关闭套接字的时候，未发送的数据会被丢弃，且另一端会出现连接被同位体重置的异常；如果 linger 非 0，则关闭套接字的线程将被阻塞，直到数据全部发送或超时，超时后的行为与底层系统相关，JDK 无法控制。如果关闭该选项，则套接字正常关闭，数据也会全部发送。由于底层实现的差异性，不提倡应用开发人员打开该选项。

设置是否延迟发送数据

该选项由 setTcpNoDelay(boolean on) 方法配置，对应底层系统的 TCP_NODELAY TCP 选项。默认值为 off。打开该选项将禁用 Nagle 算法，TCP 包会立即发送；关闭该选项则会启用 Nagle 算法，多个较小的 TCP 包会被组合成一个大包一起发送，虽然发送延迟了，但有利于避免网络拥塞。默认为 false。该选项对实时性很强的程序可能有用，但一般的程序不需要关心。

设置流量类别

该选项由 setTrafficClass(int tc) 方法配置，对应底层系统的“流量类别”套接字属性。该选项用于向网络（例如路由器）提示从该套接字发送的包需要获取哪些服务类型，对本地 TCP 协议栈没有影响。IPv4 和 IPv6 分别定义了多个不同的值，例如 IPv4 将 0x08 定义为最大吞吐量，0x10 定义为最小延迟，等等。可以用或运算将多个值合并为一个选项。该选项用来调整性能，需要根据实际情况设置。由于只是建议值，可能被网络忽略。

网上很多关于单例模式写法的文章，不外乎饿汉和懒汉两种形式的讨论。很多人喜欢用懒汉式，因为觉得它实现了延迟加载，可以让系统的性能更好。但事实果真如此吗？我对此存疑。

首先我们检查一下饿汉和懒汉单例模式最简单的写法（这里不讨论哪种懒汉写法更好）：

// 饿汉
public final class HungrySingleton {
    private static final HungrySingleton INSTANCE = new HungrySingleton();

    private HungrySingleton() {
        System.out.println("Initializing...");
    }

    public static HungrySingleton getInstance() {
        return INSTANCE;
    }
}

// 懒汉
public final class LazySingleton {
    private static LazySingleton INSTANCE;

    private LazySingleton() {
        System.out.println("Initializing...");
    }

    public static synchronized LazySingleton getInstance() {
        if (INSTANCE == null) {
            INSTANCE = new LazySingleton();
        }
        return INSTANCE;
    }
}
    

从理论上来说，HungrySingleton 的单例在该类第一次使用的时候创建，而 LazySingleton 的单例则在其 getInstance() 方法被调用的时候创建。至于网上有人声称“饿汉式不管用不用都会初始化”，纯属走路的时候步子迈得太大。谁的加载更迟？如果你只是调用它们的 getInstance() 方法来得到单例对象，则它们都是延迟加载，这样懒汉式没有任何意义，而且由于 LazySingleton 采取了同步措施，性能更低（可以说任何懒汉式的性能都低于饿汉式）。当你使用一个单例类的时候，难道第一步不是调用 getInstance() 么？所以在自己的代码里，我更喜欢用饿汉式。

下面用一个例子来测试加载顺序：

// 饿汉
System.out.println("Before");
HungrySingleton.getInstance();
System.out.println("After");

// 懒汉
System.out.println("Before");
LazySingleton.getInstance();
System.out.println("After");
    

输出结果都是：

Before
Initializing...
After

那么，懒汉模式还有什么存在意义？如果系统使用了某些需要在启动时对类进行扫描的框架，使用饿汉式的话，启动时间比懒汉式更长，如果使用了大量单例类，不利于开发阶段。在系统的正式运行阶段，所有的单例类迟早都要加载的，总的说来两者性能持平，但是懒汉式每次都至少多一个判断，所以越到后期越体现饿汉的优越性。

最后，推荐下《Effective Java》第二版指出的用枚举类型实现的饿汉单例模式：

// 饿汉
public enum HungrySingleton {
    INSTANCE;

    private HungrySingleton() {
    }
}

这种写法不但最简洁，还能轻易扩展为实例数量固定的“多例模式”。

JDK 提供了对 TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Datagram Protocol，用户数据报协议）这两个数据传输协议的支持。本文开始探讨 TCP。

TCP 基础知识

在“服务器-客户端”这种架构中，服务器和客户端各自维护一个端点，两个端点需要通过网络进行数据交换。TCP 为这种需求提供了一种可靠的流式连接，流式的意思是传出和收到的数据都是连续的字节，没有对数据量进行大小限制。一个端点由 IP 地址和端口构成（专业术语为“元组 {IP 地址, 端口}”）。这样，一个连接就可以由元组 {本地地址, 本地端口, 远程地址, 远程端口} 来表示。

连接过程

在 TCP 编程接口中，端点体现为 TCP 套接字。共有两种 TCP 套接字：主动和被动，“被动”状态也常被称为“侦听”状态。服务器和客户端利用套接字进行连接的过程如下：

1. 服务器创建一个被动套接字，开始循环侦听客户端的连接。
2. 客户端创建一个主动套接字，连接服务器。
3. 服务器接受客户端的连接，并创建一个代表该连接的主动套接字。
4. 服务器和客户端通过步骤 2 和 3 中创建的两个主动套接字进行数据传输。

下面是连接过程的图解：

TCP 连接

一个简单的 TCP 服务器

JDK 提供了 ServerSocket 类来代表 TCP 服务器的被动套接字。下面的代码演示了一个简单的 TCP 服务器（多线程阻塞模式），它不断侦听并接受客户端的连接，然后将客户端发送过来的文本按行读取，全文转换为大写后返回给客户端，直到客户端发送文本行 bye：

public class TcpServer implements Runnable {
    private ServerSocket serverSocket;

    public TcpServer(int port) throws IOException {
        // 创建绑定到某个端口的 TCP 服务器被动套接字。
        serverSocket = new ServerSocket(port);
    }

    @Override
    public void run() {
        while (true) {
            try {
                // 以阻塞的方式接受一个客户端连接，返回代表该连接的主动套接字。
                Socket socket = serverSocket.accept();
                // 在新线程中处理客户端连接。
                new Thread(new ClientHandler(socket)).start();
            } catch (IOException ex) {
                ex.printStackTrace();
            }
        }
    }
}

public class ClientHandler implements Runnable {
    private Socket socket;

    public ClientHandler(Socket socket) {
        this.socket = Objects.requireNonNull(socket);
    }

    @Override
    public void run() {
        try (Socket s = socket) {  // 减少代码量的花招……
            // 包装套接字的输入流以读取客户端发送的文本行。
            BufferedReader in = new BufferedReader(new InputStreamReader(
                    s.getInputStream(), StandardCharsets.UTF_8));
            // 包装套接字的输出流以向客户端发送转换结果。
            PrintWriter out = new PrintWriter(new OutputStreamWriter(
                    s.getOutputStream(), StandardCharsets.UTF_8), true);

            String line = null;
            while ((line = in.readLine()) != null) {
                if (line.equals("bye")) {
                    break;
                }

                // 将转换结果输出给客户端。
                out.println(line.toUpperCase(Locale.ENGLISH));
            }
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }
}
    

阻塞模式的编程方式简单，但存在性能问题，因为服务器线程会卡死在接受客户端的 accept() 方法上，不能有效利用资源。套接字支持非阻塞模式，现在暂时略过。

一个简单的 TCP 客户端

JDK 提供了 Socket 类来代表 TCP 客户端的主动套接字。下面的代码演示了上述服务器的客户端：

public class TcpClient implements Runnable {
    private Socket socket;

    public TcpClient(String host, int port) throws IOException {
        // 创建连接到服务器的套接字。
        socket = new Socket(host, port);
    }

    @Override
    public void run() {
        try (Socket s = socket) {  // 再次减少代码量……
            // 包装套接字的输出流以向服务器发送文本行。
            PrintWriter out = new PrintWriter(new OutputStreamWriter(
                    s.getOutputStream(), StandardCharsets.UTF_8), true);
            // 包装套接字的输入流以读取服务器返回的文本行。
            BufferedReader in = new BufferedReader(new InputStreamReader(
                    s.getInputStream(), StandardCharsets.UTF_8));

            Console console = System.console();
            String line = null;
            while ((line = console.readLine()) != null) {
                if (line.equals("bye")) {
                    break;
                }

                // 将文本行发送给服务器。
                out.println(line);
                // 打印服务器返回的文本行。
                console.writer().println(in.readLine());
            }

            // 通知服务器关闭连接。
            out.println("bye");
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }
}
    

从 JDK 文档可以看到，ServerSocket 和 Socket 在初始化的时候，可以设定一些参数，还支持延迟绑定。这些东西对性能和行为都有所影响。下一篇文章将详解这两个类的初始化。

我竟然到现在才发现《Fundamental Networking in Java》这本神作，真有点无地自容的感觉。最近几年做的都是所谓的企业级开发，免不了和网络打交道，但在实际工作中，往往会采用框架将底层细节和上层应用隔离开，感觉就像是在一个 Word 模板表单里面填写内容，做出来也没什么成就感。虽然没有不使用框架的理由，但我还真是有点怀念当初直接用套接字做网络编程的日子，既能掌控更多东西，还可以学到更多知识，为研究框架的实现原理打基础。闲话完毕，转入今天的正题：IP（Internet Protocol，互联网协议）。

IP 基础知识

说到 IP，大多数人的第一反应估计都是 IP 地址。其实 IP 是一种协议，IP 地址只是协议的一部分。《RFC 791 - INTERNET PROTOCOL》说：“互联网协议是为在包交换计算机通信网络的互联系统中使用而设计的。”IP 包含三方面的功能：

1. 用于查找主机的寻址系统
2. 包格式的定义
3. 传输和接收包的规则

IP 的相关 Java 类

从 Java 的角度来看上面说到的三个功能，只有第一个是开发人员需要关心的。另外两个都依赖底层系统的实现，JDK 也没有提供相关的类去操作。下面一一介绍 JDK 提供的用于处理 IP 地址的类。

InetAddress

此类用来表示 IP 地址，它有两个子类：Inet4Address 和 Inet6Address，分别用于处理 IPv4 和 IPv6 两个版本。在实际应用中，InetAddress 足以应付绝大多数情况。它提供了一些静态方法来构造实例，能根据参数格式自动识别 IP 版本：

public static InetAddress[] getAllByName(String host) throws UnknownHostException

解析指定的主机地址，并返回其所有的 IP 地址；如果传入 IP 地址字符串，则只会校验格式，返回的数组也只包含一个代表该 IP 地址的实例。例如，想看看谷歌有多少马甲的话，InetAddress.getAllByName("www.google.com") 就可以了。

public static InetAddress getByAddress(byte[] addr) throws UnknownHostException

用表示 IP 地址的字节数组（专业术语称为“原始 IP 地址”）构造一个实例。IPv4 地址必须是 4 个字节，IPv6 必须 16 个。不常用。

public static InetAddress getByAddress(String host, byte[] addr) throws UnknownHostException

用主机地址和原始 IP 地址构造一个实例。此方法应该慎用，因为它不会对主机名进行解析。即使主机名为 IP 地址字符串，也不会检查是否与字节数组一致。

public static InetAddress getByName(String host) throws UnknownHostException

用主机地址构造一个实例，也可以直接传入 IP 地址字符串，等同于 getAllByName(host)[0]。

public static InetAddress getLocalHost() throws UnknownHostException

返回本机在网络中的地址。

public static InetAddress getLoopbackAddress()

返回环回地址 127.0.0.1，不抛出异常，等同于 getByName("localhost")（不要和 getLocalHost() 搞混）。环回地址使主机能够自己连接自己，常被用来对在同一台机器上测试网络应用程序。在 IPv4 中，环回地址的网段为 127.0.0.0/8，通常用 127.0.0.1；IPv6 中只有一个 ::1。

接下来看看 InetAddress 中定义的部分实例方法：

public byte[] getAddress()

返回原始 IP 地址。

public String getCanonicalHostName()

返回全限定域名。这个方法可以用来探查实际的主机名，例如 InetAddress.getByName("www.google.com").getCanonicalHostName() 返回 we-in-f99.1e100.net。

public String getHostAddress()

返回构造时传入的主机地址。

public String getHostName()

返回主机名。如果构造时传入的主机地址为 IP 地址字符串，则调用 getCanonicalHostName()，否则直接返回构造时传入的主机地址。

public boolean isAnyLocalAddress()

检查是否为通配符地址。通配符地址为 0.0.0.0（IPv4）或 ::0（IPv6），代表所有的本地 IP 地址。例如，假设电脑有两块网卡，各有一个地址，如果想让一个程序同时监听这两个地址，就需要用通配符地址。

public boolean isLinkLocalAddress()

检查是否为链路本地地址。IPv4 里定义为地址段 169.254.0.0/16，Ipv6 里是以 fe80::/64 为前缀的地址。在电脑没联网的时候查看本机 IP，就能看到这种地址。

public boolean isLoopbackAddress()

检查是否为环回地址。

public boolean isSiteLocalAddress()

检查是否为站点本地地址。站点本地地址这个名词实际上已经过时了，现在叫唯一本地地址。IPv4 中未定义；IPv6 中定义为地址段 fc00::/7。这些地址用于私有网络，例如企业内部的局域网。

此外还有一些有关多播地址的方法，暂时略过。

JDK 默认同时支持 IPv4 和 IPv6。如果只想使用一种，可以根据情况将 java.net.preferIPv4Stack 或 java.net.preferIPv6Addresses 这两个系统属性之一设为 true。两个属性的默认值都为 false。一般来说不需要去惊动它们。

SocketAddress

该类是一个空壳，事实上应用程序使用的是它的唯一子类 InetSocketAddress，目前还看不出这样设计有什么意义。该类只不过在 InetAddress 的基础上增加了一个端口属性。

NetworkInterface

该类代表网络接口，例如一块网卡。一个网络接口可以绑定一些 IP 地址。具有多个网络接口的主机被称为多宿主主机。下面的代码可打印出所有本机网络接口的信息：

for (NetworkInterface ni : Collections.list(NetworkInterface.getNetworkInterfaces())) {
    System.out.println(ni);
    for (InterfaceAddress ia : ni.getInterfaceAddresses()) {
        System.out.println("\t" + ia);
    }
    System.out.println();
}
    

在我的笔记本上运行结果为：

name:lo (Software Loopback Interface 1)
	/127.0.0.1/8 [/127.255.255.255]
	/0:0:0:0:0:0:0:1/128 [null]
name:net0 (WAN Miniport (SSTP))
name:net1 (WAN Miniport (L2TP))
name:net2 (WAN Miniport (PPTP))
name:ppp0 (WAN Miniport (PPPOE))
name:eth0 (WAN Miniport (IPv6))
name:eth1 (WAN Miniport (Network Monitor))
name:eth2 (WAN Miniport (IP))
name:ppp1 (RAS Async Adapter)
name:net3 (WAN Miniport (IKEv2))
name:net4 (Intel(R) Wireless WiFi Link 4965AGN)
	/fe80:0:0:0:288a:2daf:3549:1811%11/64 [null]
name:eth3 (Broadcom NetXtreme 57xx Gigabit Controller)
	/10.140.1.133/24 [/10.140.1.255]
	/fe80:0:0:0:78c7:e420:1739:f947%12/64 [null]
name:net5 (Teredo Tunneling Pseudo-Interface)
	/fe80:0:0:0:e0:0:0:0%13/64 [null]
name:net6 (Bluetooth Device (RFCOMM Protocol TDI))
name:eth4 (Bluetooth Device (Personal Area Network))
name:eth5 (Cisco AnyConnect VPN Virtual Miniport Adapter for Windows x64)
name:net7 (Microsoft ISATAP Adapter)
	/fe80:0:0:0:0:5efe:a8c:185%17/128 [null]
name:net8 (Microsoft ISATAP Adapter #2)
name:net9 (Intel(R) Wireless WiFi Link 4965AGN-QoS Packet Scheduler-0000)
name:eth6 (Broadcom NetXtreme 57xx Gigabit Controller-TM NDIS Sample LightWeight Filter-0000)
name:eth7 (Broadcom NetXtreme 57xx Gigabit Controller-QoS Packet Scheduler-0000)
name:eth8 (Broadcom NetXtreme 57xx Gigabit Controller-WFP LightWeight Filter-0000)
name:eth9 (WAN Miniport (Network Monitor)-QoS Packet Scheduler-0000)
name:eth10 (WAN Miniport (IP)-QoS Packet Scheduler-0000)
name:eth11 (WAN Miniport (IPv6)-QoS Packet Scheduler-0000)
name:net10 (Intel(R) Wireless WiFi Link 4965AGN-Native WiFi Filter Driver-0000)
name:net11 (Intel(R) Wireless WiFi Link 4965AGN-TM NDIS Sample LightWeight Filter-0000)
name:net12 (Intel(R) Wireless WiFi Link 4965AGN-WFP LightWeight Filter-0000)

Exchanger 用来让两个线程互相等待并交换计算结果。这个类的用法很简单，因为它就定义了两个重载的 exchange 方法，参数多的那个无非增加了对超时的支持。当一个线程调用 exchange 的时候（以计算结果作为参数），它就开始等待另一个线程调用 exchange，然后两个线程分别收到对方调用 exchange 时传入的参数，从而完成了计算结果的交换。

不用太多的解释，运行下面这个例子就一清二楚：

final Exchanger<String> e = new Exchanger<>();

new Thread() {
    @Override
    public void run() {
        long id = Thread.currentThread().getId();
        String s = "abc";
        System.out.println("线程 [" + id + "] 算出 " + s);

        try {
            TimeUnit.SECONDS.sleep(new Random().nextInt(5));
            System.out.println("线程 [" + id + "] 收到 " + e.exchange(s));
        } catch (InterruptedException ex) {
            ex.printStackTrace();
        }
    }
}.start();

new Thread() {
    @Override
    public void run() {
        long id = Thread.currentThread().getId();
        String s = "xyz";
        System.out.println("线程 [" + id + "] 算出 " + s);

        try {
            TimeUnit.SECONDS.sleep(new Random().nextInt(5));
            System.out.println("线程 [" + id + "] 收到 " + e.exchange(s));
        } catch (InterruptedException ex) {
            ex.printStackTrace();
        }
    }
}.start();
    

运行结果（可能为）：

线程 [9] 算出 abc
线程 [10] 算出 xyz
线程 [10] 收到 abc
线程 [9] 收到 xyz

最后强调下，该类只适用于两个线程，妄图用它来处理多个生产者和消费者之间的数据交换是注定要失败的……

以前我曾用两个类（ZipItem 和 ZipSystem）实现了一个简单的 ZIP 文件系统（以下简称 ZFS）。其实这两个小类挺好用的，而且支持嵌套的 ZIP 文件，但是，但是……JDK 7 丢下来一枚叫做 NIO2 的笑气炸弹，引入了一套标准的文件系统 API，我承认我中弹了，手痒了，又根据这套 API 重新实现了 ZIP 文件系统，终于在今天初步完工，哈。

话说，JDK 7 其实捆绑销售了一个 ZFS，demo 目录下还有源代码。可……它达不到我的奢求，而且 BUG 不少。随便逮两个：

        // com.sun.nio.zipfs.ZipFileSystemProvider 类中的方法
        @Override
        public Path getPath(URI uri) {

            String spec = uri.getSchemeSpecificPart();
            int sep = spec.indexOf("!/");
            if (sep == -1)
                throw new IllegalArgumentException("URI: "
                    + uri
                    + " does not contain path info ex. jar:file:/c:/foo.zip!/BAR");
            // 难怪该方法始终抛 IllegalArgumentException 异常，原来你小子把文件的 URI
            // 当成 ZFS 的 URI 在用……
            return getFileSystem(uri).getPath(spec.substring(sep + 1));
        }

        // com.sun.nio.zipfs.ZipFileSystem 类中的方法
        @Override
        public PathMatcher getPathMatcher(String syntaxAndInput) {
            int pos = syntaxAndInput.indexOf(':');
            // 丫的，pos == syntaxAndInput.length()？！谁写的？抓出来鞭尸。
            if (pos <= 0 || pos == syntaxAndInput.length()) {
                throw new IllegalArgumentException();
    

很明显，官方 ZFS 没有经过代码审阅、没有经过测试、没有经过……然后，@author Xueming Shen，真是丢咱华夏民族的脸……

下面列个表格详细比较官方 ZFS 和山寨 ZFS：

山寨 ZFS 的用法示例：

        Map<String, Object> env = new HashMap<>();
        // 用于解码 ZIP 条目名。默认为 Charset.defaultCharset()。
        env.put("charset", StandardCharsets.UTF_8);
        // 指示是否自动探测嵌套的 ZIP 文件。默认为 false。
        env.put("autoDetect", true);
        // 默认目录，用于创建和解析相对路径。默认为“/”。
        env.put("defaultDirectory", "/dir/");

        // 从文件创建一个 ZFS。
        try (FileSystem zfs = FileSystems.newFileSystem(
                URI.create("zip:" + Paths.get("docs.zip").toUri()), env)) {
            Path path = zfs.getPath("app.jar");
            if ((Boolean) Files.getAttribute(path, "isZip")) {
                // 创建一个嵌套的 ZFS。
                try (FileSystem nestedZfs = zfs.provider().newFileSystem(path, env)) {
                    // 此处省略若干行。
                }
            }
        }
    

最后双手奉上源代码：请猛击此处！

先看出错的代码：

        public class Holder<T> {
            private T value;

            public Holder() {
            }

            public Holder(T value) {
                this.value = value;
            }

            public void setValue(T value) {
                this.value = value;
            }

            // 此处省略若干行。
        }

        Holder<Object> holder = new Holder<>("xxx");
    

看起来还好，但编译的时候却报错：

Uncompilable source code - incompatible types
  required: zhyi.test.Holder<java.lang.Object>
  found:    zhyi.test.Holder<java.lang.String>

老老实实把类型写出来就没问题：

        Holder<Object> holder = new Holder<Object>("xxx");
    

如果非要用钻石运算符的话，可以采取下列两种方式之一：

        // 使用默认构造器，再调用 setValue 方法。
        Holder<Object> holder = new Holder<>();
        holder.setValue("xxx");

        // 使用泛型通配符，但之后就不能调用 setValue 了，否则编译出错。
        Holder<? extends Object> holder = new Holder<>("xxx");
    

CyclicBarrier 的功能类似于前面说到的 CountDownLatch，用于让多个线程（子任务）互相等待，直到共同到达公共屏障点（common barrier point），在这个点上，所有的子任务都已完成，从而主任务完成。

该类构造的时候除了必须要指定线程数量，还可以传入一个 Runnable 对象，它的 run 方法将在到达公共屏障点后执行一次。子线程完成计算后，分别调用 CyclicBarrier#await 方法进入阻塞状态，直到其他所有子线程都调用了 await。

下面仍然以运动员准备赛跑为例来说明 CyclicBarrier 的用法：

            final int count = 8;
            System.out.println("运动员开始就位。");

            final CyclicBarrier cb = new CyclicBarrier(count, new Runnable() {
                @Override
                public void run() {
                    System.out.println("比赛开始...");
                }
            });

            for (int i = 1; i <= count; i++) {
                final int number = i;
                new Thread() {
                    @Override
                    public void run() {
                        System.out.println(number + " 号运动员到场并开始准备...");
                        try {
                            // 准备 2~5 秒钟。
                            TimeUnit.SECONDS.sleep(new Random().nextInt(4) + 2);
                        } catch (InterruptedException ex) {
                        }
                        System.out.println(number + " 号运动员就位。");
                        try {
                            cb.await();
                        } catch (InterruptedException | BrokenBarrierException ex) {
                        }
                    }
                }.start();
            }
            System.out.println("等待所有运动员就位...");
    

运行输出（可能）为：

运动员开始就位。
1 号运动员到场并开始准备...
2 号运动员到场并开始准备...
等待所有运动员就位...
3 号运动员到场并开始准备...
4 号运动员到场并开始准备...
6 号运动员到场并开始准备...
8 号运动员到场并开始准备...
5 号运动员到场并开始准备...
7 号运动员到场并开始准备...
1 号运动员就位。
3 号运动员就位。
8 号运动员就位。
6 号运动员就位。
2 号运动员就位。
7 号运动员就位。
5 号运动员就位。
4 号运动员就位。
比赛开始...

最后看看 CyclicBarrier 和 CountDownLatch 的主要异同：

1. 两者在构造的时候都必须指定线程数量，而且该数量在构造后不可修改。
2. 前者可以传入一个 Runnable 对象，在任务完成后自动调用，执行者为某个子线程；后者可在 await 方法后手动执行一段代码实现相同的功能，但执行者为主线程。
3. 前者在每个子线程上都进行阻塞，然后一起放行；后者仅在主线程上阻塞一次。
4. 前者可以重复使用；后者的倒计数器归零后就作废了。
5. 两者的内部实现完全不同。



蜀山兆孨龘 2011-10-17 11:21 发表评论
]]>http://www.blogjava.net/shinzey/archive/2011/10/14/361277.html蜀山兆孨龘蜀山兆孨龘Fri, 14 Oct 2011 06:22:00 GMThttp://www.blogjava.net/shinzey/archive/2011/10/14/361277.htmlhttp://www.blogjava.net/shinzey/comments/361277.htmlhttp://www.blogjava.net/shinzey/archive/2011/10/14/361277.html#Feedback1http://www.blogjava.net/shinzey/comments/commentRss/361277.htmlhttp://www.blogjava.net/shinzey/services/trackbacks/361277.html

顾名思义，CountDownLatch 是一个用来倒计数的咚咚。如果某项任务可以拆分成若干个子任务同时进行，然后等待所有的子任务完成，可以考虑使用它。

该类的用法非常简单。首先构造一个 CountDownLatch，唯一的参数是任务数量，一旦构造完毕就不能修改。接着启动所有的子任务（线程），且每个子任务在完成自己的计算后，调用 CountDownLatch#countDown 方法将倒计数减一。最后在主线程中调用 CountDownLatch#await 方法等待计数器归零。

例如赛跑的准备阶段，八名运动员先后到达起点做好准备，然后裁判打响发令枪，准备工作就结束了，比赛开始。如果把从运动员就位到发令枪响看做赛跑准备任务，那么每个运动员的准备过程就是其子任务，可以用 CountDownLatch 模拟如下：

        final int count = 8;
        System.out.println("运动员开始就位。");

        // 构造 CountDownLatch。
        final CountDownLatch cdl = new CountDownLatch(count);
        for (int i = 1; i <= count; i++) {
            final int number = i;
            new Thread() {
                @Override
                public void run() {
                    System.out.println(number + " 号运动员到场并开始准备...");
                    try {
                        // 让运动员随机准备 2~5 秒钟。
                        TimeUnit.SECONDS.sleep(new Random().nextInt(4) + 2);
                    } catch (InterruptedException ex) {
                    }
                    System.out.println(number + " 号运动员就位。");
                    // 倒计数减一。
                    cdl.countDown();
                }
            }.start();
        }

        System.out.println("等待所有运动员就位...");
        try {
            // 等待倒计数变为 0。
            cdl.await();
            System.out.println("比赛开始。");
        } catch (InterruptedException ex) {
        }
    

运行输出（可能）为：

运动员开始就位。
1 号运动员到场并开始准备...
2 号运动员到场并开始准备...
4 号运动员到场并开始准备...
等待所有运动员就位...
8 号运动员到场并开始准备...
6 号运动员到场并开始准备...
3 号运动员到场并开始准备...
7 号运动员到场并开始准备...
5 号运动员到场并开始准备...
6 号运动员就位。
1 号运动员就位。
5 号运动员就位。
4 号运动员就位。
7 号运动员就位。
8 号运动员就位。
2 号运动员就位。
3 号运动员就位。
比赛开始。

从上面的例子还可以看出 CountDownLatch 的局限性和 CompletionService 类似，在于无法处理子任务数量不确定的情况，例如统计某个文件夹中的文件数量。另外，如果某个子任务在调用 countDown 之前就挂掉了，倒计数就永远不会归零。对于这种情况，要么用 finally 之类的手段保证 countDown 一定会被调用，要么用带参数的 await 方法指定超时时间。




蜀山兆孨龘 2011-10-14 14:22 发表评论
]]>http://www.blogjava.net/shinzey/archive/2011/09/29/359781.html蜀山兆孨龘蜀山兆孨龘Thu, 29 Sep 2011 05:37:00 GMThttp://www.blogjava.net/shinzey/archive/2011/09/29/359781.htmlhttp://www.blogjava.net/shinzey/comments/359781.htmlhttp://www.blogjava.net/shinzey/archive/2011/09/29/359781.html#Feedback0http://www.blogjava.net/shinzey/comments/commentRss/359781.htmlhttp://www.blogjava.net/shinzey/services/trackbacks/359781.html

CompletionService 接口的实例可以充当生产者和消费者的中间处理引擎，从而达到将提交任务和处理结果的代码进行解耦的目的。生产者调用 submit 方法提交任务，而消费者调用 poll（非阻塞）或 take（阻塞）方法获取下一个结果：这一特征看起来和阻塞队列（BlockingQueue）类似，两者的区别在于 CompletionService 要负责任务的处理，而阻塞队列则不会。

在 JDK 中，该接口只有一个实现类 ExecutorCompletionService，该类使用创建时提供的 Executor 对象（通常是线程池）来执行任务，然后将结果放入一个阻塞队列中：果然本就是一家亲啊！ExecutorCompletionService 将线程池和阻塞队列糅合在一起，仅仅通过三个方法，就实现了任务的异步处理，可谓并发编程初学者的神兵利器！

接下来看一个例子。楼主有一大堆 *.java 文件，需要计算它们的代码总行数。利用 ExecutorCompletionService 可以写出很简单的多线程处理代码：

        public int countLines(List<Path> javaFiles) throws Exception {
            // 根据处理器数量创建线程池。虽然多线程并不保证能够提升性能，但适量地
            // 开线程一般可以从系统骗取更多资源。
            ExecutorService es = Executors.newFixedThreadPool(
                    Runtime.getRuntime().availableProcessors() * 2);
            // 使用 ExecutorCompletionService 内建的阻塞队列。
            CompletionService cs = new ExecutorCompletionService(es);

            // 按文件向 CompletionService 提交任务。
            for (final Path javaFile : javaFiles) {
                cs.submit(new Callable<Integer>() {
                    @Override
                    public Integer call() throws Exception {
                        // 略去计算单个文件行数的代码。
                        return countLines(javaFile);
                    }
                });
            }

            try {
                int loc = 0;
                int size = javaFiles.size();
                for (int i = 0; i < size; i++) {
                    // take 方法等待下一个结果并返回 Future 对象。不直接返回计算结果是为了
                    // 捕获计算时可能抛出的异常。
                    // poll 不等待，有结果就返回一个 Future 对象，否则返回 null。
                    loc += cs.take().get();
                }
                return loc;
            } finally {
                // 关闭线程池。也可以将线程池提升为字段以便重用。
                // 如果任务线程（Callable#call）能响应中断，用 shutdownNow 更好。
                es.shutdown();
            }
        }
    

最后，CompletionService 也不是到处都能用，它不适合处理任务数量有限但个数不可知的场景。例如，要统计某个文件夹中的文件个数，在遍历子文件夹的时候也会“递归地”提交新的任务，但最后到底提交了多少，以及在什么时候提交完了所有任务，都是未知数，无论 CompletionService 还是线程池都无法进行判断。这种情况只能直接用线程池来处理。




蜀山兆孨龘 2011-09-29 13:37 发表评论
]]>