亚洲?V无码乱码国产精品,国产成人亚洲综合一区,男人的天堂亚洲一区二区三区

abstract class MappedByteBuffer extends ByteBuffer

cooperzh — Fri, 06 Jan 2012 06:09:00 GMT

MappedByteBuffer ��文件直接映��到虚拟内存。可以映��整个文�Ӟ��如果文�g太大�Q�可以分�D�|��定映��?br />

通常通过FileChannel.map()�Ҏ��创徏�?/div>映射之后�Q�通过MappedByteBuffer 讉K��文�g内容�Q�比到硬盘上去读取文件要快很多�?br />

FileChannel.map()�Ҏ��创徏时指定方式：

MapMode.READ_ONLY�Q�尝试修改缓冲区则报异常ReadOnlyBufferException

MapMode.READ_WRITE�Q�共享缓冲区�Q�所有访问的�E�序都可��d��写，但写完是否其他程序立即看到变��_��未知

MapMode.PRIVATE�Q�创建副本，所有修改对同时讉K��的其他程序不可见

protected�Q?br />volatile boolean isAMappedBuffer;

MappedByteBuffer(int mark,int pos,int lim,int cap,boolean mapped);

MappedByteBuffer(mark,pos,lim,cap);

private�Ҏ��Q?br />checkMapped();
pagePosition();

public final�Ҏ��Q?br />isLoaded(); �~�存区内�Ҏ��否处于物理内存中
load(); ��缓冲区内容从虚拟内存加载到物理内存
force(); 当缓存区�?/span>MapMode.READ_WRITE模式�Ӟ��缓存区内容写入存储讑֤��?/span>

private native�Ҏ��Q?br />isLoaded0();
load0();
force0();

cooperzh 2012-01-06 14:09 发表评论

接口 Readable

cooperzh — Fri, 06 Jan 2012 03:01:00 GMT

Readable是一个字�W�源

public�Ҏ��Q?br />read(CharBuffer); ��字�W�读入指定的�~�冲�?/div>

cooperzh 2012-01-06 11:01 发表评论

接口 Appendable

cooperzh — Fri, 06 Jan 2012 02:58:00 GMT

表示可以向char序列��d��字符(有效的Unicode字符)

�Ҏ��有：
append(char);
append(CharSequence);
append(CharSequence csq, int start, int end);

cooperzh 2012-01-06 10:58 发表评论

接口 Comparable

cooperzh — Thu, 05 Jan 2012 15:54:00 GMT

public �Ҏ��
compareTo�Ҏ��Q�比较两个对象的内容
�q�回值由实体�c�d��体定义，通常�?1,0,1

实现了该接口的实体类��有了彼此比较的能力

实现了该接口的实体类的数�l�，在��用sort()卛_��实现自动排序。因为sort内部会调�?/span>compareTo()来比较大��。这��是实现Comparable接口的好�?/span>

cooperzh 2012-01-05 23:54 发表评论

cooperzh — Thu, 05 Jan 2012 15:35:00 GMT

19 块注�?/* */)不能可靠的注释掉代码块，应用单行注释�W?/

cooperzh 2012-01-05 23:35 发表评论

接口 CharSequence

cooperzh — Thu, 05 Jan 2012 13:24:00 GMT

CharSequence �?char 值的一个可��d��?br />
最基本的char存储协议

�Ҏ��Q?/h2>
charAt(int index);
�q�回长度是序列中16位char的数�?/li>
length();
subSequence(int start, int end);
toString();

cooperzh 2012-01-05 21:24 发表评论

cooperzh — Tue, 27 Dec 2011 09:36:00 GMT

作者blog:http://pengjiaheng.iteye.com/

数据�c�d��Q�基本类型和引用�c�d��
基本�c�d��的变量保存原始��|��它代表的值就是数值本�w�。byte,short,int,long,char,float,double,Boolean,returnAddress
引用�c�d��代表某个对象的引用，存放引用值的地址。类�c�d��Q�接口类型，数组

栈stack �?堆heap:
stack是运行时单位�Q�每个线�E�都会有�U�程栈与之对应。里面存储的是当前线�E�相关信息。包括局部变量，�E�序�q�行状态，�Ҏ��q�回值等
heap是存储数据的地方�Q�所有线�E�共享。存攑֯�象信息�?br />
1 从��Y件设计的角度看，stack代表处理逻辑�Q�heap代表数据�?br />2 heap的数据被多个�U�程�׃�n�Q�则多个�U�程可以讉K��同一对象。heap的数据可以供所有stack讉K��Q�节省了�I�间
3 stack因�ؓ�q�行时的需要，保存�pȝ��q�行的上下文�Q�需要进行地址�D늚�划分。�ƈ且只能向上增长，因此限制了stack的存储能力。而heap中的数据可以�Ҏ��需要动态增长，相应stack中只需要记录heap中的一个地址卛_��?br />4 面向对象��是stack和heap的完��结构。对象的属性就是数据，存放在heap中。而对象的�Ҏ��是�q�行逻辑�Q�放在stack中�?br />
在java中，main函数��是stack的�v点，也是�E�序的�v炏V�?br />
heap中存攄��是对象实例，stack中是基本数据�c�d��和heap中对象的引用。一个对象的大小是不可以估计的，甚至动态变化的。但是在stack中，一个对象只对应了一�?byte的引用。这��是stack和heap分离的好处�?br />
因�ؓ基本数据�c�d��占用的空间是1�?个字节，需要空间比较小�Q�而且不会出现动态增长的情况�Q�因此stack中存储就够了�?br />
java中参��C��递时传��D��是传引用�Q?br />�E�序永远在stack中运行，因而参��C��递的只是基本�c�d��或者对象的引用。不会传递对象本�w��?br />��单说�Q�java在方法调用传递参数时�Q�都是进行传��D��用�?br />当传递引用的时候，�E�序会将引用查找到heap中的那个对象�Q�这个时候进行修改，修改的是真实的对象，而不是引用本�w�！�Q�！
所以传递引用也是传递的最�l�倹{�?br />另外�Q�因��Z��递基本类型是传递了基本��|��所以修改的也是另一个copy�Q�而无法修改原倹{��只有传递的是对象引用时才能修改原对象�?/span>

stack是程序运行最�Ҏ��的东�ѝ��程序运行可以没有heap�Q�但必须有stack�?br />
java中，stack的大��是通过-Xss来设�|�的�Q�当stack中数据比较多�Ӟ��需要适当调大�q�个��|��否则会出现java.long.StackOverflowError异常

Java对象的大��?br />一个空object的大��是8byte�Q�这个大��只是保存heap中一个没有�Q何属性的对象大大��。如�Q?br />Object o = new Object();
它所占的�I�间�?byte + 8byte�?byte为stack中保存对象引用需要的�I�间�Q?byte是heap中对象的信息�?br />因�ؓ所有java非基本类型对象都是集成自Object�Q�所以不��Z��么样的java对象�Q�大��都必须大于8byte

1
2 Class NewObject{
3     int count;
4     boolean flag;
5     Object o;
6 }

其大��ؓ�Q�对象大��?8) + int�?4) + boolean(1) + 对象引用(4) = 17byte
但是因�ؓjava在内存中对对象进行分配时都是�?的倍数来分配，因此会�ؓNewObject对象实例分配 24byte�?/span>

需要注意基本类型的包装�c�d��的大��。因为包装类型已�l�成为对象了�Q�因此要把包装类型当对象来看待。如Integer,Float,Double�{?br />一个包装类型最��占�?6byte(8的倍数)�Q�它是��用基本类型的N倍，因此��量��用包装�c�R�?br />
对象引用分�ؓ�Q�强引用�Q��Y引用�Q�弱引用和虚引用�?br />1 强引用StrongReference�Q�我们一般声明对象时jvm生成的引用，强引用环境下�Q�垃圑֛�攉��要严格判断。如果被强引用则不会被回�?br />2 软引用SoftReference�Q�一般作为缓存来使用。在垃圾回收的时候，jvm会根据当前系�l�的剩余内存来决定是否对软引用进行回收。如果jvm发生outOfMemory�Ӟ��肯定是没有��Y引用存在的�?br />3 弱引用WeakReference�Q�与软引用类��|��都是作�ؓ�~�存来��用。不同的是在垃圾回收的时候，弱引用一定会被回收。因此其生命周期只存在一个垃圑֛�收周期内�?br />4 虚引用PhantomReference�Q��Ş同虚设，随时会被垃圾回收。其主要功能是与引用队列(ReferenceQueue)联合使用。当垃圾回收发现一个对象有虚引用时�Q�就会在回收内存之前�Q�将虚引用添加到与之兌��的引用队列中。程序可以通过判断引用队列中是否有虚引用来了解引用对象是否��要被回收。从而决定是否采取行动�?br />
�pȝ��一般��用强引用。��Y引用和弱引用一般是在内存大��比较受限的情况下��用。常用在桌面引用�pȝ��中�?br />

垃圾回收基本��法
1 引用计数 Reference Counting
古老的回收��法。对象多一个引用，��增加一个计敎ͼ�删除一个引用则减少一个计数。垃圑֛�收时�Q�只攉��计数�?的对象�?br />该算法最致命的是无法处理循环引用的问题�?br />2 标记-清除 Mark-Sweep
此算法分��Z��个阶�D�c��第一阶段从引用根节点开始标记所有被引用的对象，�W�二阶段遍历整个heap�Q�把未标记的对象清除�?br />此算法需要暂停整个应用。同时��生内存碎片�?br />3 复制 Copying
此算法把�I�间划分�?个相�{�的区域。每�ơ只使用其中一个区域。垃圑֛�收时�Q�遍历当前��用区域，把正在��用中的对象复制到另一个区域中。此��法每次只处理正在��用中的对象，因此复制成本比较��，同时复制�q�去以后�q�能�q�行相应的内存整理，不会出现��片�?br />此算法的�~�点是需要两倍的内存�I�间�?br />4 标记-整理 Mark-Compact
此算法结合了 Mark_Sweep �?Copying 两个��法的优炏V�?br />�W�一阶段从根节点开始标记所有被引用对象�Q�第二阶�D�遍历整个heap�Q�清除未标记对象�q�且把存�z�d��象压�~�到heap的其中一块，按照��序摆放�?br />此算法避免了��片问题�Q�和Copying��法的空间问题�?br />
5 增量攉�� Incremental Collecting
实时垃圾回收��法�Q�在应用�q�行的同时进行垃圑֛��Ӟ��jdk5 没有使用此算�?br />6 分代攉�� Generational Collecting
��Z��对对象生命周期分析后得出的垃圑֛�收算法。把对象分�ؓ�q�青代、年老代、持久代�Q�对不同周期的对象采用不同的��法�Q�上面算法的一个）�q�行回收�?br />
7 串行攉��
使用单线�E�处理所有垃圑֛�收工作，因�ؓ无序多线�E�交互，更容易实玎ͼ�而且效率很高。但是无法��用多处理器的优势�Q�所以只适合单处理器的机器�?br />8 �q�行攉��
使用多线�E�处理垃圑֛�收工作速度快，效率高。理��Z��cpu数目��多�Q�越能体现�ƈ行收集的优势
9 �q�发攉��
前面两个在进行垃圑֛�收的时候，需要暂停整个运行环境。因此系�l�会有明昄��暂停�Q�暂停时间因为heap��大而越�ѝ�?br />

垃圾回收面��的问�?br />
1 如何区分垃圾�Q?br />因�ؓ引用计数无法解决循环引用。所有后来的垃圾回收��法都是从程序运行的根节点出发，遍历整个对象引用�Q�查扑֭��zȝ��对象。因为stack是真正进行程序执行的地方�Q�所以要知道哪些对象正在被��用，需要从java stack开始。如果有多个�U�程�Q�必��d��q�些�U�程对应的所有stack�q�行��查�?br />除了stack外，�q�有�pȝ��q�行时的寄存器，也是存储�E�序�q�行时数据的地方。这样以stack和寄存器中的引用��v点，来找到heap中的对象�Q�又从这些对象中扑ֈ�对heap中其他对象的引用�Q�这样逐步扩展。最�l�以null引用或基本类型结束，�q�样��Ş成了一��以java stack中引用所对应的对象�ؓ根节点的一��对象数。如果stack中有多个引用�Q�则最�l��Ş成多��对象树。这些对象树上的对象�Q�都是当前系�l�运行所需要的对象�Q�不能被回收。而其他剩余对象，视�ؓ无法被引用的对象�Q�可以被回收�?br />因此垃圾回收的�v�Ҏ��一些根对象(java stack�Q�static 变量�Q�寄存器……)。最��单的java stack��是main函数。这�U�回收方式，��是Mark-Sweep�?br />
2 如何处理��片�Q?br />因�ؓ不同java对象存活旉��不同�Q�因此程序运行一�D�|��间后�Q�会出现零散的内存碎片。碎片最直接的问题就是导致无法分配大块的内存�I�间�Q�以及程序运行效率降低。Copying和Mark-Compact都可以解决碎片问�?br />
3 如何解决同时存在的对象创建和对象回收问题
垃圾回收�U�程是回收内存的�Q�程序运行是消耗内存的�Q�一个回收内存，一个分配内存，两者是毛段的。因此，在现有的垃圾回收方式中，在垃圑֛�收前�Q�一般都需要暂停整个应用（暂停内存分配�Q�，然后�q�行垃圾回收�Q�回收完成后再��l�应用�?br />�q�样的弊端是�Q�当heap�I�间持箋增大�Ӟ��垃圾回收的时间也��相应增长，相应的程序暂停时间也增长。一些对旉��要求很高的应用，比如最大暂停时间要求是几百ms�Q�那么当heap�I�间大于几个G�Ӟ��可能超时。这�U�情况下�Q�垃圑֛�收会成�ؓ�pȝ��q�行的一个瓶颈。�ؓ了解册��个矛盾，有了�q�发垃圾回收��法。��用这个算法，垃圾回收�U�程与程序运行线�E�同时运行。没有暂停，��法复杂性会大大增加�Q�系�l�处理能力也相应降低。同时碎片问题将会比较难解决�?br />

分代垃圾回收详述�Q?br />1 ��Z��么要分代�Q?br />��Z��q�样一个事实：不同对象的生命周期是不一��L��。因此不同生命周期的对象可以采取不同的收集方式，以便提高回收效率�?br />在java�q�行�q�程中会产生大量对象。其中有些对象是与业务信息相关的。比如http��h��中的session对象、线�E�、socket�q�接�Q�这些跟业务直接挂钩�Q�因此生命周期比较长。但是程序运行过�E�中生成的��时变量，生命周期会比较短。比如String对象�{��?br />
2 如何分代�Q?br />jvm中共划�ؓ三个代：�q�轻�?Young Generation)、年老代(Old Generation)、持久代(Permanent Generation)
持久代主要存放Java�c�M��息，与垃圑֛�收要攉��的java对象关系不大。年青代和年老代是对垃圾攉��影响最大的�?br />
�q�轻代：
1 所有新生成的对象首先都是放�?#8220;�q�轻�?里的。年��M��的目标就是尽可能快速的攉��那些生命周期短的对象�?br />�q�轻代分��Z��个区�Q?个Eden区，2个Survivor(�q�存�Q�残�?�?br />大部分对象在Eden区生成，当Eden区满�Ӟ��q�存�zȝ��对象��被复制到Survivor1区，当Survivor1区满�Ӟ��此区的存�z�d��象将被复制到Survivor2区，此时�Q?/span>Eden区满时还存活的对象将复制到Survivor2中，Survivor1��Z��被清�I?/span>�?/span>当Survivor2��Z��满时�Q�包含从1中复制过来的对象和从Eden��来的对象�Q�，从Survivor1区复制过来的�q�且�q�存�zȝ��对象�Q�将被复制到"�q�老代"的年老区(Tenured Space)。Survivor2��Z��新增加的从Eden��来的�q�存�zȝ��对象�Q�将复制到Survivor1中，Survivor2被清�I�。之后，Eden区满时还存活的对象就会复制到Survivor1中。重复这��L��循环�?/span>
两个Survivor区是对称的，没有先后��序。所以同一个区中可能同时存在从Eden复制�q�来的对象和另一个Survivor区复制过来的对象�?br />而复制到�q�老代的Tenured区的只有从第一个Survivor��来的对象�Q�因为Tenured区存攄��是从�W�一个Survivor��来，依旧存活的对象�?br />两个Survivor��Z��L��一个是�I�的。同时根据需要，可以配置多个Survivor区，廉��对象在年��M��中的存在旉��Q�减��被攑ֈ��q�老代的可能�?br />2 �q�老代
在年��M��中经历了N�ơ垃圑֛�收后仍然存活的对象，��׃��被放到年老代。因此年老代存放的都是生命周期较长的对象�?br />3 持久�?br />用于存放静态文�Ӟ��如java�c�，�Ҏ��{��?br />持久代对垃圾回收没有显著影响�Q�但是有些应用可能动态生成或者调用一些class�Q�例如Hibernate�{�，在这�U�时候需要设�|�一个比较大的持久代�I�间来存放这些运行过�E�中新增的类。持久代大小通过-XX:MaxPermSize=�q�行讄��?br />
什么情况下触发垃圾回收�Q?br />�׃��对象�q�行了分代处理，因此垃圾回收区域、时间也不一栗��?br />GC(Garbage Collection)有两�U�类型：Scavenge GC �?Full GC
1 Scavenge GC
一般情况下�Q�当新对象生成，�q�且在Eden区申��L��间失败时�Q�就会触发Scavenge GC。对Eden��行GC�Q�清除非存活对象�Q��ƈ且把��且存活的对象移动到Survivor区。然后整理Survivor的两个区。这�U�方式的GC是对�q�轻代的Eden��行，不会影响到年老代�?br />因�ؓ大部分对象都是从Eden区开始的�Q�同时Eden��Z��会分配的很大�Q�所以Scavenge GC 会频�J�进行�?br />一般这里需要��用速度快，效率高的��法�Q��Eden区尽快空闲出来�?br />2 Full GC
�Ҏ��个Heap�q�行整理�Q�包括年��M��Q�年老代和持久代。Full GC因�ؓ需要对整个�q�行回收�Q�所以比Scavenge GC要慢�Q�因此应该尽可能减少Full GC的次数。在对jvm调优的过�E�中�Q�很大一部分工作��是对Full GC的调节。导致Full GC是因为如下方法：

�q�老代的Tenured��写满
持久代被写满
System.gc()被显式调�?/li>
上一�ơGC之后Heap的各区域分配�{�略动态变�?/li>

选择合适的垃圾攉��法
1 串行攉��?br />用单�U�程处理所有垃圑֛�收工作，因�ؓ无需多线�E�交互，所以效率比较高。但是，无法使用多处理器的优势，所以只适合单处理器机器�?br />也可以用在小数据�?100M)情况下的多处理器机器上。用-XX:+UseSerialGC打开

2 �q�行攉��?br />对年��M��q�行�q�行垃圾回收�Q�因此可以减��垃圑֛�收时间。一般在多线�E�多处理器上使用。��?XX:+UseParallelGC打开�?br />�q�行攉��器在J2SE5.0更新上引入，在java SE6.0中进行了增强�Q�可以对�q�老代�q�行攉��。如果年老代不��用�ƈ发收集的话，默认是��用单�U�程�q�行垃圾回收�Q�因此会制约扩展能力。��?XX:+UseParallelOldGC打开�?br />讄��Q?br />

�q�行垃圾回收的线�E�数�Q��?XX:ParallelGCThreads=。此值可以设�|�与机器处理器数量相�{��?/li>
最大垃圑֛�收暂停，指定垃圾回收时的最长暂停时��_��通过-XX:MaxGCPauseMillis=指定。N为毫�U�，如果指定了此��|��heap大小和垃圑֛�收相兛_��C��q�行调整以达到指定倹{��设定此��g��减少应用吞吐量�?br />
吞吐量，为垃圑֛�收时间与非垃圑֛�收时间的比��|��通过-XX:GCTimeRatio=来设定，公式�?/(1+N)。例如，N=19�Ӟ��表示5%的时间用于垃圑֛�收。默认值是99�Q�即�?%的时间用于垃圑֛�收�?br />

3 �q�发攉��?br />可以保证大部分工作都�q�发�q�行(应用不停�?�Q�垃圑֛�收只暂停很少的时��_��此收集器适合对响应时间要求比较高的大中规模应用�?br />使用-XX:+UseConcMarkSweepGC打开�?br />�q�发攉��器主要减��年老代的暂停时��_��它在应用不停止的情况下��用独立的垃圾回收�U�程�Q�跟�t�可辑֯�象。在每个�q�老代垃圾回收周期中，在收集出气�ƈ发收起会�Ҏ��个应用进行简短的暂停�Q�在攉��中还会再暂停一�ơ。第二次暂停旉��比第一�ơ稍长，在此�q�程中多个线�E�同时进行垃圑֛�收工作�?br />�q�发攉��器��用处理器换来短暂的停��时间�?br />在一个N个处理器的系�l�上�Q��ƈ发收集部分��用K/N个可用处理器�q�行回收�Q�一般情况下1<=K<=N/4。即K��于N的四分之一�?br />在只有一个处理器的主��Z��使用�q�发攉��器，讄��为incremental mode模式也可以获得较短的停顿旉��?br />
��动垃圾(Floating Garbage)�Q?br />�׃��在应用运行的同时�q�行垃圾回收�Q�所以有些垃圑֏�能在垃圾回收�q�行完成时��生，�q�样��造成�?#8220;Floating Garbage”�Q�这些垃��N��要在下次垃圾回收周期时才能回收掉。所有，�q�发攉��器一般需要预�?0%的空间用于��Q动垃圾�?br />
�q�发模式��p�|(Concurrent Mode Failure):
�q�发攉��器在应用�q�行时进行收集，所以需要保证heap在垃圑֛�收的�q�段旉��有��够的�I�间供程序��用，否则�Q�垃圑֛�收还未完成，heap�I�间先满了。这�U�情况下��׃��发生�q�发模式��p�|�Q�此时整个应用会暂停�Q�进行垃圑֛�收�?br />��Z��保证有��够内存供�q�发攉��器��用，可以讄��-XX:CMSInitiatingOccupancyFraction=指定剩余多少heap时开始执行�ƈ发收集�?br />
1 串行serial攉��器，适用于数据量比较��?100M)的应用，或者单处理器下�q�且对响应时间无要求的应用�?br />�~�点�Q�只能用于小型应�?br />2 �q�行parallel攉��器，适用于对吞吐量有高要求，多cpu�Q�对应用相应旉��无要求的大中型应用。如后台处理、科学计��?br />�~�点�Q�垃圾收集过�E�中应用响应旉��可能加长
3 �q�发concurrent攉��器：适用于对响应旉��有高要求�Q�多cpu的大中型应用。如web服务器、应用服务器、电信交换、集成开发环境�?br />

P26……

cooperzh 2011-12-27 17:36 发表评论

《构建高性能的大型分布式Java应用》笔�?�W�一�?IO

cooperzh — Tue, 27 Dec 2011 03:50:00 GMT

IO三种方式�Q�BIO�Q�NIO�Q�AIO (异步��d��asynchronous IO)

jdk1.6及之前都只实现BIO �?NIO
jdk1.7开始支持AIO�Q�即NIO 2.0

在BIO��d��模式下server�?
1 new ServerSocket(int port) 监听端口
2 serverSocket.accept() ��d��式等待客��L��的连接，有连接才�q�回Socket对象
3 socket.getINputStream() 获取客户端发�q�来的信息流
4 socket.getOutputStream() 获取输出��对象，从而写入数据返回客��L��

client端：
1 newSocket�Q�String host,int port) 建立与服务器端的�q�接�Q�如果服务器没启动，报Connection refused异常
2 socket.getInputStream() ��d��服务器端�q�回的流
3 socket.getOutputStream() 获取输出��，写入数据发送到服务器端

在NIO模式下Server端：
1 ServerSocketChannel.open() 获取serverScoketChannel实例
2 serverScoketChannel.configueBlocking(false) 讄��channel为非��d��模式
3 serverSocketChannel.socket() 获取serverSocket对象
4 serverSocket.bind(port) 监听端口
5 Selector.open() 打开Selector�Q�获取selector实例
6 serverSocketChannel.register(Selector,int) 向selector注册channel和感兴趣的事�?/span>
7 while(true) 循环以保证正常情况下服务器端一直处于运行状�?/span>
8 selector.select() 获取selector实例中需要处理的SelectionKey的数�?/span>
9 for(SelectionKey key:selector.selectedKeys()) 遍历selector.selectedKeys,以对每个SelectionKey的事件进行处�?/span>
10 key.isAcceptable() 判断SelectionKey的类型是否�ؓ客户端徏立连接的�c�d��
11 key.channel() 当SelectionKey的类型是acceptabel�Ӟ��获取�l�定的ServerSocketChannel对象
12 serverSocketChannel.accept() 接受客户端徏立连接的��h��Q��ƈ�q�回SocketChannel对象
13 socketChannel.regiseter(Selector,int) 向Selector注册感兴��的事�g�c�d��Q�如read,write
14 key.isReadable() 判断SelectionKey是否为readable�Q�如是则意味着有消息流在等待处�?/span>
15 socketChannel.read(ByteBuffer) 从SelectionKey中绑定的SocketChannel对象��d��消息��?/span>
16 socketChannel.write(ByteBuffer) 从SelectionKey中绑定的SocketChannel对象输出消息��?/span>

client端：

1 SocketChannel.open() 打开SocketChannel

2 SocketChannel.configureBlocking(false) ��SocketChannel配置为非��d��模式

3 SocketChannel.connect(host,port) �q�接到指定的目标地址

4 Selector.open() 打开Selector

5 SocketChannel.register(Selector,int) 向Selector注册感兴��的事�g,connected,read,write

6 while(true) 循环执行保证客户端一直处于运行状�?/span>

7 Selector.select() 从Selector中获取是否有可读的key信息

8 for(SelectionKey key:selector.selectedKeys()) 遍历selector中所有selectedKeys

9 SelectionKey.isConnectable() 判断是否��接徏立的�c�d��

10 SelectionKey.channel() 获取�l�定的SocketChannel

11 SocketChannel.finishConnect() 完成�q�接的徏立（TCP/IP的三�ơ握手）

12 SelectionKey.isReadable() 判断是否为可�ȝ��?/span>

13 SelectionKey.channel() 获取�l�定的SocketChannel

14 SocketChannel.read(ByteBuffer) 从SocketChannel中读取数到ByteBuffer�?/span>

15 SocketChannel.write(ByteBuffer) 向SocketChannel中写入ByteBuffer对象数据

cooperzh 2011-12-27 11:50 发表评论

Tricks and Tips With AIO Part 1: The Frightening Thread Pool �Q��{载）

cooperzh — Thu, 22 Dec 2011 04:01:00 GMT

from: Tricks and Tips With AIO Part 1: The Frightening Thread Pool

Jean-Francois

A while ago JDK 1.4 introduced the notion of non-blocking I/O. With non-blocking I/O (NIO), you're getting events through a selector when there is some I/O ready to be processed, like read and write operations. before JDK 1.4, only blocking I/O was available. With locking I/O, you were just blocking on a stream, trying to read and write.

JDK 7 introduces asynchronous I/O (AIO). Asynchronous I/O gives you a notification when the I/O is completed. The big difference with non-blocking is with AIO you get the notification when the I/O operation complete, where with blocking you you get notified when the I/O operation is ready to be completed.

For example, with a socket channel in a non-blocking mode, you register with a selector, and the selector will give you a notification when there is data on that socket to read. With the asynchronous I/O, you actually start the read, and the I/O will complete sometime later when the read has happened and there is data in your byte buffer.

With AIO, you wait for completed I/O operation using we a completion handler (explained in details below). You specify a completion handler when you do your read, and the completion handler is invoked to tell you that the I/O operation has completed with the bytes that has been read. With non-blocking, you would have been notified and then you would have executed yourself the read operation to read bytes.

One of the nice thing you can do with AIO is to configure yourself the thread pool the kernel will uses to invoke a completion handler. A completion handler is an handler for consuming the result of an asynchronous I/O operation like accepting a remote connection or reading/writing some bytes. So an asynchronous channels (with NIO.1 we had SelectableChannel) allow a completion handler to be specified to consume the result of an asynchronous operation. The interface define three "callback":

* completed(...): invoked when the I/O operation completes successfully.

* failed(...): invoked if the I/O operations fails (like when the remote client close the connection).

* cancelled(...): invoked when the I/O operation is cancelled by invoking the cancel method.

Below is an example (I will talk about it it much more details in part II) of how you can open a port and listen for requests:

1 // Open a port
2 final AsynchronousServerSocketChannel listener =
3    AsynchronousServerSocketChannel.open().bind(new InetSocketAddress(port));
4
5 // Accept connections
6 listener.accept(null, new CompletionHandler() {
7    public void completed(AsynchronousSocketChannel channel,Void> result) {}
8    public void cancelled(AsynchronousSocketChannel channel,Void> result) {}
9    public void failed(AsynchronousSocketChannel channel,Void> result) {}
10 }
11

Now every time a connection is made to the port, the completed method will be invoked by a kernel's thread. Do you catch the difference with NIO.1? To achieve the same kind of operation with NIO.1 you would have listen for requests by doing:

1 selector.select(timeout);
2
3 while(readyKeys.hasNext()){
4  SelectionKey key = iterators.next();
5  if (key.isAcceptable()){
6    // Do something that doesn't block
7    // because if it blocks, no more connection can be
8    // accepted as the selector.select(..)
9    // cannot be executed
10  }
11 }
12

With AIO, the kernel is spawning the thread for us. Where this thread coming from? This is the topic of this Tricks and Tips with AIO.

By default, applications that do not create their own asynchronous channel group will use the default group that has an associated thread pool that is created automatically. What? The kernel will create a thread pool and manage it for me? Might be well suited for simple application, but for complex applications like the Grizzly Framework, relying on an 'external' thread pool is unthinkable as most of the time the application embedding Grizzly will configure its thread pool and pass it to Grizzly. Another reason is Grizzly has its own WorkerThread implementation that contains information about transactions (like ByteBuffer, attributes, etc.). At least the monster needs to be able to set the ThreadFactory!.

Note that I'm not saying using the kernel's thread pool is wrong, but for Grizzly, I prefer having full control of the thread pool. So what's my solution? There is two solutions, et c'est parti:

Fixed number of Threads (FixedThreadPool)

An asynchronous channel group associated with a fixed thread pool of size N creates N threads that are waiting for already processed I/O events. The kernel dispatch event directly to those threads, and those thread will first complete the I/O operation (like filling a ByteBuffer during a read operation). Once ready, the thread is re-used to directly invoke the completion handler that consumes the result. When the completion handler terminates normally then the thread returns to the thread pool and wait on a next event. If the completion handler terminates due to an uncaught error or runtime exception, the thread is returned to the pool and wait for new events as well (no thread are lost). For those cases, the thread is allowed to terminate (a new event is submitted to replace it). The reason the thread is allowed to terminate is so that the thread (or thread group) uncaught exception handler is executed.

So far so good? ....NOT. The first issue you must be aware when using fixed thread pool is if all threads "dead lock" inside a completion handler, your entire application can hangs until one thread becomes free to execute again. Hence this is critically important that the completion handler's methods complete in a timely manner so as to avoid keeping the invoking thread from dispatching to other completion handlers. If all completion handlers are blocked, any new event will be queued until one thread is 'delivered' from the lock. That can cause a really bad situation, is it? As an example, using a Future when waiting for a read operation to complete can lock you entire application:

1 Future result = ((AsynchronousSocketChannel)channel).read
2               (byteBuffer,,myCompletionHandler);
3
4    try{
5        count = result.get(30, TimeUnit.SECONDS);
6    } catch (Throwable ex){
7        throw new EOFException(ex.getMessage());
8    }
9

Like for OP_WRITE, I'm pretty sure nobody will ever code something like that, right? Well, some application needs to blocks until all the bytes are arrived (a Servlet Container is a good example) and if you don't paid attention, your server might hangs. Not convinced? Another example could be:

1 channel.write(bb,30,TimeUnit.SECONDS,db_pool,new CompletionHandler() {
2
3            public void completed(Integer byteWritten, DataBasePool attachment) {
4                // Wait for a jdbc connection, blocking.
5                MyDBConnection db_con = attachment.get();
6            }
7
8            public void failed(Throwable exc, DataBasePool attachment) {
9            }
10
11            public void cancelled(DataBasePool attachment) {
12            }
13        });
14

Again, all threads may dead lock waiting for a database connection and your application might stop working as the kernel has no thread available to dispatch and complete I/O operation.

Grrr what's our solution? The first solution consists to carefully avoid blocking operations inside a completion handler, meaning any threads executing a kernel event must never block on something. I suspect this will be simple to achieve if you write an application from zero and you want to have a fully asynchronous application. Still, be careful and make sure you properly create enough threads. How you do that? Here is an example from Grizzly:

1 ThreadPoolExecutorServicePipeline executor = new ThreadPoolExecutorServicePipeline
2 (corePoolThreads,maxThreads,8192,30,TimeUnit.SECONDS);
3 AsynchronousChannelGroup asyncChannelGroup = AsynchronousChannelGroup
4 .withFixedThreadPool(executor,maxThreads);
5

The second solution is to use a cached thread pool

Cached Thread Pool Configuration

An asynchronous channel group associated with a cached thread pool submits events to the thread pool that simply invoke the user's completion handler. Internal kernel's I/O operations are handled by one or more internal threads that are not visible to the user application. Yup! That means you have one hidden thread pool (not configurable via the official API, but as a system property) that dispatch events to a cached thread pool, which in turn invokes completion handler (Wait! you just win a price: a thread's context switch for free ;-). Since this is a cached thread pool, the probability of suffering the hangs problem described above is lower. I'm not saying it cannot happens as you can always create cached thread pool that cannot grows infinitely (those infinite thread pool should have never existed anyway!). But at least with cached thread pool you are guarantee that the kernel will be able to complete its I/O operations (like reading bytes). Just the invocation of the completion handler might be delayed when all the threads are blocked. Note that a cached thread pool must support unbounded queueing to works properly. How you do set a cached thread pool? Here is an example from Grizzly:

1 ThreadPoolExecutorServicePipeline executor = new ThreadPoolExecutorServicePipeline
2      (corePoolThreads,maxCachedThreadPoolSize,8192,
3            30,TimeUnit.SECONDS);
4 AsynchronousChannelGroup asyncChannelGroup = AsynchronousChannelGroup
5       .withCachedThreadPool(executor,maxCachedThreadPoolSize);
6

What about the default that ship with the kernel?

If you do not create your own asynchronous channel group, then the kernel's default group that has an associated thread pool will be created automatically. This thread pool is a hybrid of the above configurations. It is a cached thread pool that creates threads on demand, and it has N threads that dequeue events and dispatch directly to the application's completion handler. The value of N defaults to the number of hardware threads but may be configured by a system property. In addition to N threads, there is one additional internal thread that dequeues events and submits tasks to the thread pool to invoke completion handlers. This internal thread ensures that the system doesn't stall when all of the fixed threads are blocked, or otherwise busy, executing completion handlers.

Conclusion

If you have one thing to learn from this part I is independently of which thread pool you decide to use (default, your own cached or fixed), make sure you at least limit blocking operations. This is specially true when a fixed thread pool is used as it may hangs your entire application as the kernel is running out of available threads. The situation can also occurs with cached thread pool, but at least the kernel can still execute the I/O operations.

cooperzh 2011-12-22 12:01 发表评论

NIO trick and trap NIO的技巧与陷阱

cooperzh — Tue, 20 Dec 2011 12:41:00 GMT

出处�Q?a title="http://www.tkk7.com/killme2008/archive/2011/06/30/353422.html" href="http://www.tkk7.com/killme2008/archive/2011/06/30/353422.html">http://www.tkk7.com/killme2008/archive/2011/06/30/353422.html

IO划分��Z��个阶�D�：

1 �{�待数据��q�A

2 从内核缓冲区copy到进�E�缓冲区�Q�从socket通过socketChannel复制到ByteBuffer�Q?/span>

non-direct ByteBuffer: HeapByteBuffer�Q�创建开销��?/span>

direct ByteBuffer�Q�通过操作�pȝ��native代码�Q�创建开销�?/span>

��Z��block的传输通常比基于流的传输更高效

使用NIO做网�l�编�E�容易，但离散的事�g驱动模型�~�程困难�Q�而且陷阱重重

Reactor模式�Q�经典的NIO�|�络框架

核心�l��g�Q?/span>

1 Synchronous Event Demultiplexer : Event loop + 事�g分离

2 Dispatcher�Q�事件派发，可以多线�E?/span>

3 Request Handler�Q�事件处理，业务代码

理想的NIO框架�Q?/span>

1 优雅地隔��IO代码和业务代�?/span>

2 易于扩展

3 易于配置�Q�包括框架自�w�参数和协议参数

4 提供良好的codec框架�Q�方便marshall/unmarshall

5 透明性，内置良好的日志记录和数据�l�计

6 高性能

NIO框架性能的关键因�?/span>

1 数据的copy

2 上下文切�?context switch)

3 内存��理

4 TCP选项�Q�高�U�IO函数

5 框架设计

减少数据copy�Q?/span>

ByteBuffer的选择

View ByteBuffer

FileChannel.transferTo/transferFrom

FileChannel.map/MappedByteBuffer

ByteBuffer的选择�Q?/span>

不知道用哪种buffer�Ӟ��用Non-Direct

没有参与IO操作�Q�用Non-Direct

中小规模应用(<1K�q�发�q�接)�Q�用Non-Direct

长生命周期，较大的缓冲区�Q�用Direct

��试证明Direct比Non-Direct更快�Q�用Direct

�q�程间数据共�?JNI)�Q�用Direct

一个Buffer发给多个Client�Q�考虑使用view ByteBuffer�׃�n数据�Q�buffer.slice()

HeapByteBuffer�~�存

使用ByteBuffer.slice()创徏view ByteBuffer�Q?/span>

ByteBuffer buffer2 = buffer1.slice()�Q?/span>

则buffer2的内容和buffer1的从position到limit的数据内容完全共�?/span>

但是buffer2的position�Q�limit是独立于buffer1�?/span>

传输文�g的传�l�方式：

byte[] buf = new byte[8192];

while(in.read(buf)>0){

out.write(buf);

}

使用NIO后：

FileChannel in = ...

WriteableByteChannel out = ...

in.transferTo(0,fsize,out);

性能会有60%的提�?/span>

FileChannel.map

��文件映��ؓ内存区域——MappedByteBuffer

提供快速的文�g随机��d��能力

�q�_��相关

适合大文�Ӟ��只读型操作，如大文�g的MD5校验�{?/span>

没有unmap�Ҏ��Q�什么时候被回收取决于GC

减少上下文切�?/span>

旉��~�存

Selector.wakeup

提高IO��d��效率

�U�程模型

旉��~�存�Q?/span>

1�|�络服务器通常需要频�J�获取系�l�时��_��定时器，协议旉��戻I��~�存�q�期�{?/span>

2 System.currentTimeMillis

a linux调用gettimeofday需要切换到内核�?/span>

b 普通机器上�Q?000万次调用需�?2�U�，�q�_��一��?.3毫秒

c 大部分应用不需要特别高的精�?/span>

3 SystemTimer.currentTimeMillis�Q�自己创建）

a 独立�U�程定期更新旉��~�存

b currentTimeMillis直接�q�回�~�存�?/span>

c �_�ֺ�取决于定期间�?/span>

d 1000万次调用降低�?9毫秒

Selector.wakeup() 主要作用�Q?/span>

解除��d��在Selector.select()上的�U�程�Q�立卌��?/span>

两次成功的select()之间多次调用wakeup�{��h于一�ơ调�?/span>

如果当前没有��d��在select()上，则本�ơwakeup��作用在下次select()�?/span>

什么时候wakeup() �Q?/span>

注册了新的Channel或者事�?/span>

Channel关闭�Q�取消注�?/span>

优先�U�更高的事�g触发�Q�如定时器事�Ӟ��Q�希望及时处�?/span>

wakeup的原理：

1 linux上利用pipe调用创徏一个管�?/span>

2 windows上是一个loopback的tcp�q�接�Q�因为win32的管道无法加入select的fd set

3 ��管道或者tcp�q�接加入selected fd set

4 wakeup向管道或者连接写入一个字�?/span>

5 ��d��的select()因�ؓ有IO旉��q�A�Q�立卌��?/span>

可见wakeup的调用开销不可忽视

减少wakeup调用�Q?/span>

1 仅在有需要时才调用。如往�q�接发送数据，通常是缓存在一个消息队列，当且仅当队列为空时注册write�q�wakeup

booleanneedsWakeup=false;

synchronized(queue){

if(queue.isEmpty()) needsWakeup=true;

queue.add(session);

}

if(needsWakeup){

registerOPWrite();

selector.wakeup();

}

2 记录调用状态，避免重复调用�Q�例如Netty的优�?/span>

��d��或者写�?个字节：

不代表连接关�?/span>

高负载或者慢速网�l�下很常见的情况

通常的处理方法是�q�回�q��l�注册read/write�Q�等待下�ơ处理，�~�点是系�l�调用开销和线�E�切换开销

其他解决办法�Q��@环一定次数写入（如Mina�Q�或者yield一定次�?/span>

启用临时选择器Temporary Selector在当前线�E�注册�ƈpoll�Q�例如Girzzy�?/span>

在当前线�E�写入：

当发送缓冲队列�ؓ�I�的时候，可以直接往channel写数据，而不是放入缓冲队列，interest了write�{�待IO�U�程写入�Q�可以提高发送效�?/span>

优点是可以减��系�l�调用和�U�程切换

�~�点是当前线�E�中断会引�vchannel关闭

�U�程模型

selector的三个主要事�Ӟ��read�Q�write�Q�accept�Q�都可以�q�行在不同的�U�程�?/span>

通常Reactor实现��Z��个线�E�，内部�l�护一个selector

1 Boss Thread + worker Thread

boss thread处理accept�Q�connect

worker thread处理read�Q�write

Reactor�U�程数目�Q?/span>

1 Netty 1 + 2 * cpu

2 Mina 1 + cpu + 1

3 Grizzly 1 + 1

常见�U�程模型�Q?/span>

1 read和accept都运行在reactor�U�程�?/span>

2 accept�q�行在reactor�U�程上，read�q�行在单独线�E?/span>

3 read和accept都运行在单独�U�程

4 read�q�行在reactor�U�程上，accept�q�行在单独线�E?/span>

选择适当的线�E�模型：

�c�echo应用�Q�unmashall和业务处理的开销非常低，选择模型1

模型2�Q�模�?�Q�模�?的accept处理开销很低

最佳选择�Q�模�?。unmashall一般是cpu-bound�Q�而业务逻辑代码一般比较耗时�Q�不要在reactor�U�程处理

内存��理

1 java能做的事情非常有�?/span>

2 �~�冲区的��理

a 池化。ThreadLocal cache�Q�环形缓冲区

b 扩展。putString,getString�{�高�U�API�Q�缓冲区自动扩展和�׾~�，处理不定长度字节

c 字节��序。跨语言通讯需要注意，默认字节��序Big-Endian�Q�java的IO库和class文�g

数据�l�构的选择

1 使用��单的数据�l�构�Q�链表，队列�Q�数�l�，散列�?/span>

2 使用j.u.c框架引入的�ƈ发集合类�Q�lock-free�Q�spin lock

3 ��M��数据�l�构都要注意定w��限制�Q�OutOfMemoryError

4 适当选择数据�l�构的初始容量，降低GC带来的媄�?/span>

定时器的实现
1 定时器在�|�络�E�序中频�J��?br /> a 周期事�g的触�?br /> b 异步��时的通知和移�?br /> c 延迟事�g的触�?br />2 三个旉��复杂�?br /> a 插入定时�?br /> b 删除定时�?br /> c PerTickBookkeeping�Q�一�ơtick内系�l�需要执行的操作
3 Tick的方�?br /> Selector.select(timeout)
Thread.sleep(timeout)

定时器的实现�Q�链�?br />��定时器�l�织成链表结�?br />插入定时器，加入链表��N��
删除定时�?br />

PerTickBookkeeping�Q�遍历链表查找expire事�g

定时器的实现�Q�排序链�?/div>��定时器�l�织成有序链表结构，按照expire截止旉��升序排序
插入定时器，扑ֈ�合适的位置插入
删除定时�?br />

PerTickBookkeeping�Q�直接从表头找�v

定时器的实现�Q�优先队�?/div>��定时器�l�织成优先队列，按照expire截止旉��作�ؓ优先�U�，优先队列一般采用最��堆实现
插入定时�?br />删除定时�?br />

PerTickBookkeeping�Q�直接取root判断

定时器的实现�Q�Hash wheel timer

��定时器�l�织成时间轮
指针按照一定周期旋转，一个tick跛_��一个槽�?br />定时器根据�g时时间和当前指针位置插入到特定槽�?br />

插入定时�?br />删除定时�?/div>

PerTickBookkeeping

槽位和tick军_��了精度和延时

定时器的实现�Q�Hierarchical Timing

Hours Wheel�Q�Minutes Wheel�Q�Seconds Wheel

�q�接IDLE的判�?br />1 �q�接处于IDLE状态：一�D�|��间没有IO��d��事�g发生
2 实现方式�Q?br /> a 每次IO��d��都记录IO��d��写的旉��?br /> b 定时扫描所有连接，判断当前旉��和上一�ơ读或写的时间差是否��过讑֮�阀��|��过卌��接处于IDLE状态，通知业务处理�?br /> c 定时的方式：��Z��select(timeout)或者定时器。Mina�Q�select(timeout);Netty:HashWheelTimer

合理讄��TCP/IP选项�Q�有时会起到显著效果�Q�需要根据应用类型、协议设计、网�l�环境、OS�q�_��{�因素做考量�Q�以��试�l�果为准

Socket�~�冲��|�选项�Q�SO_RCVBUF �?SO_SNDBUF
Socket.setReceiveBufferSize/setSendBufferSize 仅仅是对底层�q�_��的提�C�，是否有效取决于底层��^台。因此get�q�回的不是真实的�l�果�?br />讄��原则�Q?br />1 以太�|�上�Q?k通常是不够的�Q�增加到16k�Q�吞吐量增加�?0%
2 Socket�~�冲区大��至��应该是�q�接的MSS的三倍，MSS=MTU+40�Q�一�?/span>以太�|�卡的MTU=1500字节�?br /> MSS�Q�最大分�D�大��?br /> MTU�Q�最大传输单�?br />3 send buffer最好与对端的receive buffer��寸一�?br />4 对于一�ơ性发送大量数据的应用�Q�增加缓冲区�?8k�?4k可能是唯一最有效的提高性能的方式�?br /> ��Z��最大化性能�Q?/span>send buffer臛_��要跟BDP(带宽延迟乘积)一样大�?span style="font-size: 11px; ">
5 同样�Q�对于大量接收数据的应用�Q�提高接收缓冲区�Q�能减少发送端的阻�?br />6 如果应用既发送大量数据，又接收大量数据，�?/span>send buffer�?span class="Apple-style-span" style="font-size: 11px; ">receive buffer应该同时增加
7 如果讄��的ServerSocket�?span class="Apple-style-span" style="font-size: 11px; ">receive buffer��过RFC1323定义�?4k�Q�那么必��d��l�定端口前设�|�，以后accept产生的socket��承这一讄��
8 无论�~�冲区大��多��，你都应该��可能地帮助TCP臛_��以那样大��的块写�?br />

BDP(带宽延迟乘积)

��Z��优化TCP吞吐量，发送端应该发送��够的数据包以填满发送端和接收端之间的逻辑通道
BDP = 带宽 * RTT

Nagle��法�Q�SO_TCPNODELAY
通过��缓冲区内的��包自动相连�l�成大包�Q�阻止发送大量小包阻塞网�l�，提高�|�络应用效率对于实时性要求较高的应用(telnet、网�?�Q�需要关闭此��法
Socket.setTcpNoDelay(true) 关闭��法

Socket.setTcpNoDelay(false)

打开��法�Q�默�?br />
SO_LINGER选项�Q�控制socket关闭后的行�ؓ
Socket.setSoLinger(boolean linger,int timeout)
1 linger=false�Q�timeout=-1
当socket��d��close�Q�调用的�U�程会马上返回，不会��d��Q�然后进入CLOSING状态，�D�留在缓冲区中的数据��l�发送给对端�Q��ƈ且与对端�q�行FIN-ACK协议交换�Q�最后进入TIME_WAIT状�?br />

2 linger=true�Q�timeout>0

调用close的线�E�将��d��Q�发生两�U�可能的情况�Q�一是剩余的数据�l�箋发送，�q�行关闭协议交换�Q�二是超时过期，剩余数据��被删除�Q?/span>�q�行FIN-ACK协议交换

3 linger=true�Q�timeout=0

�q�行所�?#8220;hard-close”�Q��Q何剩余的数据��被丢弃�Q��ƈ且FIN-ACK交换也不会发生，替代产生RST�Q�让对端抛出“connection reset”的SocketException
4 慎重使用此选项�Q�TIME_WAIT状态的价��|��
    可靠实现TCP�q�接�l�止
    允许老的分节在网�l�中��失�Q�防止发�l�新的连�?br /> 持箋旉��=2*MSL�Q�MSL为最大分节生命周期，一般�ؓ30�U�到2分钟�Q?span style="font-size: 11px; ">

SO_REUSEADDR�Q�重用端�?br />Socket.setReuseAddress(boolean) 默认false
适用场景�Q?br />1 当一个��用本地地址和端口的socket1处于TIME_WAIT状态时�Q�你启动的socket2要占用该地址和端口，��p��用到此选项
2 SO_REUSEADDR允许同一端口上启动一个服务的多个实例�Q�多个进�E�）�Q�但每个实例�l�定的地址是不能相同的
3 SO_REUSEADDR允许完全相同的地址和端口的重复�l�定。但�q�只用于UDP的多播，不适用TCP

SO_REUSEPORT
listen做四元组�Q�多�q�程同一地址同一端口做accept�Q�适合大量短连接的web server
Freebsd独有

其他选项�Q?br />Socket.setPerformancePreferences(connectionTime, latency, bandwidth) 讄��q�接旉��、�g�q�、带宽的相对重要�?br />Socket.setKeepAlive(boolean) �q�是TCP层的keep-alive概念�Q�非HTTP协议的。用于TCP�q�接保活�Q�默认间�?��时�Q�徏议在应用层做心蟩
Socket.sendUrgentData(data) 带外数据

技巧：
1 ��d��公��^
Mina限制一�ơ写入的字节��C��过最大的�ȝ��冲区�?.5�?br />2 针对FileChannel.transferTo的bug
Mina判断异常�Q�如果是temporarily unavailable的IOException�Q�则认�ؓ传输字节��Cؓ0
3 发送消息，通常是放入一个缓冲区队列注册write�Q�等待IO�U�程��d��
�U�程切换�Q�系�l�调�?br /> 如果队列为空�Q�直接在当前�U�程channel.write�Q�隐患是当前�U�程的中断会引�v�q�接关闭
4 事�g处理优先�U?br /> ACE框架推荐�Q�accept > write > read (推荐)
Mina �?Netty�Q�read > write
5 处理事�g注册的顺�?br /> 在select()之前
在select()之后�Q�处理wakeup竞争条�g

Java Socket实现在不同��^��C��的差�?br />�׃��各种OS�q�_��的socket实现不尽相同�Q�都会媄响到socket的实�?br />需要考虑性能和健壮�?br />

cooperzh 2011-12-20 20:41 发表评论