这种IO策略的扩展性非常好，并且安全。我们可以根据需要改变selector的大小，以及worker线程池，并且在处理特定NIO事件时，如果发生了某些问题，也不会影响到注册在相同Selector上的其它Channels。
2．Same-thread IOStrategy.
Potentially最高效的IO策略。不同于worker-thread IO 策略，该策略在当前线程中处理NIO事件，可以避免线程上下文切换的巨大成本(expensive[1])。 [1] someOSes do a great job optimizing the thread context switches, but we still suppose it as relatively expensive operation.
这种策略仍然是可扩展的，因为可以调整selector线程池的大小，但是它有缺点。需要注意的是，channel NIO事件处理不会阻塞，或者执行任何的长连接操作。因为这会阻塞发生在相同Selector上的其它NIO事件。
3．Dynamic IOStrategy.
前边两种策略都各有优点和缺点。但是如果有一种策略，在运行时，可以根据当前状态(load, gathered statistics…etc)，在这两种策略间切换呢？
这种策略可能会有很多优点，例如允许对资源的细粒度控制。但是不要让条件评估逻辑超负载，否则它的复杂度会使得这种策略比前两种策略更低效。
4．Leader-follower IOStrategy.
The last IOStrategy included with Grizzly 2.3, is the leader-follower strategy:
这种IO策略类似于worker-thread IO策略，但不是将NIO事件传给worker线程，而是将控制传递给worker线程，然后worker线程变成selector线程，原selector线程负责处理NIO事件。
Grizzly 2.3 provides general interface org.glassfish.grizzly.IOStrategy:
publicinterfaceIOStrategyextendsWorkerThreadPoolConfigProducer { /**
* The {@linkorg.glassfish.grizzly.nio.SelectorRunner} will invoke this
* method to allow the strategy implementation to decide how the * {@linkIOEvent} will be handled. *
* @param connection the {@link Connection} upon which the provided * {@linkIOEvent} occurred.
* @paramioEvent the {@linkIOEvent} that triggered execution of this * strategy *
* @returntrue, if this thread should keep processing IOEvents on
* the current and other Connections, or false if this thread * should hand-off the farther IOEvent processing on any Connections, * which means IOStrategy is becoming responsible for continuing IOEvent * processing (possibly starting new thread, which will handle IOEvents). *
* @throwsIOException if an error occurs processing the {@linkIOEvent}. */
booleanexecuteIoEvent(final Connection connection, finalIOEventioEvent) throwsIOException; /**
* The {@linkorg.glassfish.grizzly.nio.SelectorRunner} will invoke this * method to allow the strategy implementation to decide how the * {@linkIOEvent} will be handled. *
* @param connection the {@link Connection} upon which the provided * {@linkIOEvent} occurred.
* @paramioEvent the {@linkIOEvent} that triggered execution of this * strategy
* @paramisIoEventEnabledtrue if IOEvent is still enabled on the
* {@link Connection}, or false if IOEvent was preliminary disabled * orIOEvent is being simulated. *
* @returntrue, if this thread should keep processing IOEvents on
* the current and other Connections, or false if this thread * should hand-off the farther IOEvent processing on any Connections, * which means IOStrategy is becoming responsible for continuing IOEvent * processing (possibly starting new thread, which will handle IOEvents). *
* @throwsIOException if an error occurs processing the {@linkIOEvent}. */
booleanexecuteIoEvent(final Connection connection, finalIOEventioEvent, finalbooleanisIoEventEnabled) throwsIOException; }
And the IOStrategy implementation may decide what to do with the specific NIO event processing.
Grizzly 2.3 带有四个预定义的IO策略实现，如上所述： 1. org.glassfish.grizzly.strategies.WorkerThreadIOStrategy 2. org.glassfish.grizzly.strategies.SameThreadIOStrategy 3. org.glassfish.grizzly.strategies.SimpleDynamicThreadStrategy 4. org.glassfish.grizzly.strategies.LeaderFollowerIOStrategy
每个Transport分配一个策略，因此可以通过Transport的get/setIO策略方法得到/设置IO策略。TCP和UDP传输默认使用worker-thread IO策略。
1.3 Transports and Connections
Transport and Connection represent the core network API in Grizzly 2.3.
Transport定义网络传输，例如TCP或者UDP，包含相关的资源(线程池，内存管理等)以及嵌
套连接的默认配置。
在Grizzly 2.3中，Connection代表一个单一网络连接（和socket很像），根据传输的类型，可以是TCP连接，或UDP连接，或任意自定义连接类型。 Transport和Connection是1对多的关系：
? Transports
上边是完整的类图，Grizzly 2.3有两个Transport实现：NIO TCP和NIO UDP，都是基于Java NIO，未来将会支持基于NIO 2的transports，如果安装了JDK 7，SCTP会被添加进来。 接下来将简要介绍下上图中的组件：
?
MemoryManager implements the memory allocation/release logic (see the Memory
management section);
? ?
ExecutorService represents the Transport associated thread-pool
Processor transport default Processor logic, which is responsible for processing NIO events.
Processors are assigned per Connection, so this one will be taken as the default one, but each Connection may have own customized Processor
? ?
Strategy implements IOStrategy (see I/O Strategies section)
NIOChannelDistributoris responsible for distributing newly created Connections among
Transport NIO Selector threads
?
SelectorRunnerimplements single Selector thread logic, which selects ready NIO events
and passes them to the Processor, which will process it according to the Strategy logic
?
SelectionKeyHandleris a wrapper over SelectionKey operations, also:
