WatchService = Inotify + poll

why poll not epoll. because epoll has higher overhead。

epoll 维护了两个队列一个是pending list（非活跃的）， 一个是ready list(活跃的). 所有准备好的event 都会在ready list里面，所以获取活跃的事件只需要O(1)的时间复杂度，而poll只维护了一个队列，要想获取活跃的event 需要遍历list 时间复杂度为O(n)。

-------------------------------------------进入正题------------------------------------------

我们先来看看在linux 下WatchService的实现LinuxWatchService 的构造函数，有几点需要说明，LinuxWatchService在构造函数中会初始化一个inotify实例，并且创建一个socket pair (两个关联的socket实例)，LinuxWatchService所有的事情都会交给poller thread去处理，自己只维护一个 LinkedBlockingDeque<WatchKey> pendingKeys 用于获取准备好的WatchKey.如下图中的LinuxWatchService的类注释所说，poller thread 会处理两个重要的事情，一个是处理request (主要是对 inotify watch list 上添加和删除item)其对应的jdk上层api就是Path类中  WatchKey register(WatchService watcher, WatchEvent.Kind<?>... events).另外一件事是处理inotify实例上面通过poll 获取的events。

下面来看看poller thread 是如何处理上面提到的两件事情。通过poll 获取 inotify 上面和socketpair[0]上面的event. inotify上面获取到的event是我们关心的StandardWatchEventKinds.ENTRY_MODIFY,StandardWatchEventKinds.ENTRY_DELETE,StandardWatchEventKinds.ENTRY_CREATE 这些事件。而socketpair[0]上面获取到的事件是通知我们处理上面提到的Requests.至于socketpair[0]上面的事件是如何产生的？我们可以看看poller类的wakeup方法。其实就是对socktpair[0]关联的socktpair[1]执行了一个写操作，socktpair[0]就能获取到事件了