在本羊讀大學的時候，Thread讓本羊雲裡霧裡，代碼寫的痛不欲生，真的是讓本羊腦袋裡很多“線”纏繞在一起。
之後，Task讓本羊代碼寫的飛起，甚至有時候根本不需要Task的時候還是要寫上，那樣顯得檔次較高：多線程！充分利用CPU！niubility！
再之後，async/await語法糖橫空出世，更讓本羊欲罷不能！
然而，
好東西吃多了總會膩的——吃貨
常在河邊走，哪有不濕鞋？——文藝青年
出來混總是要還的——“四道槓”騷年
飙車一時爽，“全家”火葬場——老司機
扯遠了，反正大概意思就是，async/await 也會有不爽的時候。
比如：UdpClient.ReceiveAsync()
某領導：只等待5秒，過時不候。這樣比較節約性能。
——哎喲，很有道理的樣子，那就改改？
於是，本羊很快就找到了一個屬性：UdpClient.Client.ReceiveTimeout
UdpClient.Client.ReceiveTimeout=5000；//領導說了只等5秒 <--注釋在這裡
var r=UdpClient.ReceiveAsync();
……（省略其他代碼）
看到沒，本羊還很善意的給代碼加上了“注釋”，方便其他小伙伴理解本羊的優雅的高深的簡潔的代碼。
然後拿起水杯，小小的抿了一口，伸出右手食指，輕輕的按下“F5”，左手在桌子上很有節奏的敲了5下，哎喲，啥情況？
再敲5下，再敲5下，再敲5下……
好吧，本羊輸了。
是時候打開MSDN了，原來，ReceiveTimeout這玩意兒只對同步方法有效，ReceiveAsync根本不管這Y的。
再研究研究？
經過一番刻苦鑽研，新的代碼來了：
var t=new CancellationTokenSource();//這玩意兒就是用來配合Task，做取消功能的
Task.Delay(5000, t.Token).ContinueWith(task =>
{
if (!task.IsCanceled && task.IsCompleted)//不是被取消而且已經完成
{
client.Close();//釋放UdpClient
}
});//咱走著瞧（不會阻塞當前線程），5秒之後再來
try
{
var r=await client.ReceiveAsync();
return r;//返回結果
}
catch
{
throw new TimeoutException("過時不候!");//優雅的拋出錯誤提示
}
以上代碼使用了很長一段時間，直到今天本羊又看到一些關於Task的文章，原來還有更優雅的實現方式！
不多說，上代碼：
var t=new CancellationTokenSource();//又是這玩意兒
var r=await Task.WhenAny(client.ReceiveAsync(), Task.Delay(5000, t.Token)) as Task<UdpReceiveResult>;//還是5秒，過時不候
if(r!=null)//如果是Delay先返回，是不能 as Task<UdpReceiveResult>的，r=null。
{
t.Cancel();//取消那個Delay，其實也可以不用處理，反正5秒後那家伙就自己去西天了
return r.Result;
}
else
{
client.Close();//釋放UdpClient，不然還是在ReceiveAsync
throw new TimeoutException("過時不候!");
}
本文到此結束，各位新老司機，點個贊吧！
PS：其實本羊的工作一直是單槍匹馬，意思就是公司裡只有本羊一個程序猿，所以，某領導是沒有的，其他小伙伴也是沒有的，一切的一切都是本羊虛構的，包括你們。
