為什么.NET定時(shí)器僅限于15 ms的分辨率？請(qǐng)注意，我詢問的東西將經(jīng)常調(diào)用回調(diào)函數(shù)，每15毫秒使用如下System.Threading.Timer..我不是在問如何使用這樣的方法精確地計(jì)時(shí)一段代碼System.Diagnostics.Stopwatch甚至QueryPerformanceCounter.另外，我讀過相關(guān)的問題：精確的Windows計(jì)時(shí)器？System.Timers.Timer()限制在15毫秒以內(nèi).NET中的高分辨率定時(shí)器這兩種方法都沒有給我的問題提供一個(gè)有用的答案。此外，推薦的MSDN文章，為Windows實(shí)現(xiàn)持續(xù)更新的高分辨率時(shí)間提供程序是關(guān)于計(jì)時(shí)，而不是提供連續(xù)的滴答聲。上面寫著。....有很多關(guān)于.NET計(jì)時(shí)器對(duì)象的錯(cuò)誤信息。例如,System.Timers.Timer被稱為“為服務(wù)器應(yīng)用程序優(yōu)化的高性能計(jì)時(shí)器”。和System.Threading.Timer被認(rèn)為是二等公民。傳統(tǒng)觀點(diǎn)認(rèn)為System.Threading.Timer是Windows的包裝器定時(shí)器隊(duì)列定時(shí)器而那System.Timers.Timer完全是另外一回事。但現(xiàn)實(shí)卻大不相同。System.Timers.Timer只是一個(gè)很薄的組件包裝器System.Threading.Timer(只需使用Reflector或ILDASM窺視內(nèi)部System.Timers.Timer你會(huì)看到System.Threading.Timer)，并且有一些代碼可以提供自動(dòng)線程同步，這樣您就不必這樣做了。System.Threading.Timer，事實(shí)證明不是定時(shí)器隊(duì)列定時(shí)器的包裝器。至少在從.NET 2.0到.NET 3.5使用的2.0運(yùn)行時(shí)中沒有。使用共享源CLI幾分鐘就可以看出，運(yùn)行時(shí)實(shí)現(xiàn)了自己的定時(shí)器隊(duì)列，類似于計(jì)時(shí)器隊(duì)列定時(shí)器，但實(shí)際上從未調(diào)用Win 32函數(shù)?？磥?NET 4.0運(yùn)行時(shí)也實(shí)現(xiàn)了自己的計(jì)時(shí)器隊(duì)列。我的測試程序(見下文)在.NET 4.0下提供了與.NET 3.5相似的結(jié)果。我已經(jīng)為計(jì)時(shí)器隊(duì)列計(jì)時(shí)器創(chuàng)建了自己的托管包裝器，并證明了我可以獲得1ms的分辨率(非常準(zhǔn)確)，所以我認(rèn)為我不太可能讀錯(cuò)CLI源代碼。我有兩個(gè)問題：首先，是什么原因?qū)е逻\(yùn)行時(shí)對(duì)計(jì)時(shí)器隊(duì)列的實(shí)現(xiàn)如此緩慢？我不能超過15毫秒的分辨率，而且精確度似乎在-1到+30毫秒之間。也就是說，如果我要求24毫秒，我將得到任何距離從23到54毫秒的滴答。我想我可以花更多的時(shí)間與CLI源代碼一起尋找答案，但我認(rèn)為這里的人可能知道。其次，我意識(shí)到這很難回答，為什么不使用計(jì)時(shí)器隊(duì)列定時(shí)器呢？我意識(shí)到.NET 1.x必須在沒有這些API的Win9x上運(yùn)行，但它們自Windows 2000以來就已經(jīng)存在了，如果我沒有記錯(cuò)的話，這是.NET 2.0的最低要求。是因?yàn)镃LI必須在非Windows機(jī)器上運(yùn)行嗎？