一、需求和初步实现
很简单的一个windows服务：客户端连接邮件服务器，下载邮件(含附件)并保存为.eml格式，保存成功后删除服务器上的邮件。实现的伪代码大致如下：
var messageCount = client.GetMessageCount(); // 邮箱中现有邮件数
if (messageCount > recordCount)
{
messageCount = recordCount;
}
if (messageCount < 1)
{
break;
}
var listAllMsg = new List<Message>(messageCount); //用于临时保存取出的邮件
//2、取出邮件后填充至列表，每次最多recordCount封邮件
for (int i = 1; i <= messageCount; i++) //邮箱索引是基于1开始的，索引范围: [1, messageCount]
{
listAllMsg.Add(client.GetMessage(i)); //取出邮件至列表
}
//3、遍历并保存至客户端，格式为.eml
foreach (var message in listAllMsg)
{
var emlInfo = new System.IO.FileInfo(string.Format("{0}.eml", Guid.NewGuid().ToString("n")));
message.SaveToFile(emlInfo);//保存邮件为.eml格式文件
}
//4、遍历并删除
int messageNumber = 1;
foreach (var message in listAllMsg)
{
client.DeleteMessage(messageNumber); //删除邮件（本质上，在关闭连接前只是打上DELETE标签，并没有真正删除）
messageNumber++;
}
//5、断开连接，真正完成删除
client.Disconnect();
if (messageCount < recordCount)
{
break;
}
}
}
}
</div>
开发中接收邮件的时候使用了开源组件Mail.Net（实际上这是OpenSMTP.Net和OpenPop两个项目的并集），调用接口实现很简单。代码写完后发现基本功能是满足了，本着在稳定的基础上更快更有效率的原则，最终进行性能调优。
二、性能调优及产生BUG分析
暂时不管这里的耗时操作是属于计算密集型还是IO密集型，反正有人一看到有集合要一个一个遍历顺序处理，就忍不住有多线程异步并行操作的冲动。有条件异步尽量异步，没有条件异步，创造条件也要异步，真正发挥多线程优势，充分利用服务器的强大处理能力，而且也自信中规中矩写了很多多线程程序，这个业务逻辑比较简单而且异常处理也较容易控制（就算有问题也有补偿措施，可以在后期处理中完善它），理论上每天需要查收的邮件的数量也不会太多，不会长时间成为CPU和内存杀手，这样的多线程异步服务实现应该可以接受。而且根据分析，显而易见，这是一个典型的频繁访问网络IO密集型的应用程序，当然要从IO处理上下功夫。
1、收取邮件
从Mail.Net的示例代码中看到，取邮件需要一个从1开始的索引，而且必须有序。如果异步发起多个请求，这个索引怎么传入呢？必须有序这一条开始让我有点犹豫，如果通过Lock或者Interlocked等同步构造，很显然就失去了多线程的优势，我猜可能还不如顺