在高压力的情况下，性能怎么样呢？对一次性直接写成功、失败的次数进行统计。如果成功次数远大于失败的次数，说明性能良好。（如果失败次数远大于成功的次数，则关闭这种直接写的操作，改用第一种方案。同时在日志里记录警告）在我自己的应用系统中，实验结果数据证明该方案的性能良好。
事实上，网络数据可分为两种到达发送情况：一是分散的数据包，例如每间隔40ms左右，发送接收35个MTU（或更小，这样就没超过默认的8K系统缓存）。二是连续的数据包，例如每间隔1s左右，连续发送接收20个MTU（或更多）。回来查了资料，发现以下两种方式：第三种方式：使用EdgeTriggered（边沿触发），这样socket有可写事件，只会触发一次。可以在应用层做好标记。以避免频繁的调用epoll_ctlEPOLL_CTL_ADDEPOLL_CTL_MOD。这种方式是epoll的ma
手册里推荐的方式，性能最高。但如果处理不当容易出错，事件驱动停止。第四种方式：在epoll_ctl使用EPOLLONESHOT标志，当事件触发以后，socket会被禁止再次触发。需要再次调用epoll_ctl（EPOLL_CTL_MOD），才会接收下一次事件。这种方式可以禁止
socket可写事件，应该也会同时禁止可读事件。会带来不便，同时并没有性能优势，因为epoll_ctl（）有一定的操作代价。2，从socket读数据时，socket缓存里的数据，可能超过用户缓存的长度，如果处理？可以调用realloc，扩大原有的缓存块尺寸。但是临时申请内存的有一定性能损失。这种情况要看接收缓存的方式。第一种方式：使用100k的大接收缓存为例。如果要等待数据，并进行解析。可能发生缓存不够的情况。此时只能扩充缓存，或先处理100k的数据，再接收新的数据。
3
f腾讯公司后台服务器经典面试题2009年5月
第二种方式：使用缓存队列，分成8K大小的队列。不存在接收缓存不够的情况。除非用户解析已出错，使用数据接收、使用脱勾。这种方式的代价是，可能需要将缓存队列再次拷贝、拼接成一块大的缓存，再进行解析。而在本人的系统中，只需要将socket接收的数据再次原样分发给客户，所以这种方案是最佳方案。3，向socket发送数据时，可能只发送了用户缓存里的一半，然后失败，如何处理？记录缓存的偏移量。下一次socket写事件时，再从偏移的位置接着发送。
那个面试官居然对这个问题问了我两次，看来我解释的不够清晰。。。。。。郁闷。4，C的虚函数是怎么实现的？使用虚函数表。回来查下资料：C对象使用虚表，如果是基类的实例，对应位置存放的是基类的函数指针；如果r