Stopwatch.Gettimestamp会翻车吗?或者后退
本文关键字：或者 Gettimestamp Stopwatch | 更新日期: 2023-09-27 18:21:16
在使用Stopwatch.GetTimestamp（）时，我们发现如果您记录返回值，然后继续调用它并与以前的返回值进行比较，它最终会返回一个小于原始值的值，但这是不可预测的。
这是预期的行为吗？
在生产代码中这样做的目的是获得微秒级的精确系统时间。
该技术包括分别调用DateTime.UtcNow和Stopwatch.GetTimestamp（）作为originalUtcNow和originalTimestamp。
从那时起，应用程序只需调用Stopwatch.GetTimestamp（），并使用Stopwatch.Frequency计算原始时间戳变量的差值，然后将该差值添加到原始UtcNow。
然后，沃伊拉。。。高效且精确的微秒DateTime。
但是，我们发现有时Stopwatch.GetTimestamp（）会返回更低的数字。
这种情况很少发生。我们的想法是在这种情况发生时简单地"重置"并继续下去。
然而，这让我们怀疑Stopwatch.GetTimestamp（）的准确性，或者怀疑.Net库中存在错误。
如果你能对此有所了解，请这样做。
仅供参考，基于当前时间戳值、频率和长度。MaxValue除非是硬件问题，否则它在我们的一生中似乎不太可能翻车。
编辑：我们现在计算这个值"每个线程"，然后"夹紧它"，以观察内核之间的跳跃来重置它。
您可能会及时跳转，因为您的线程正在跳转核心。请参阅本页的"备注"：http://msdn.microsoft.com/en-us/library/ebf7z0sw.aspx
Stopwatch类的行为因系统而异，具体取决于硬件支持。
请参阅：http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.ishighresolution.aspx
此外，我相信底层等效的win32调用（QueryPerformanceCounter）包含有用的文档：http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904（v=vs.85）.aspx
我不知道关于向后运行的确切信息（这听起来像是一个小的向后更改），但到目前为止，我已经经历了三次Stopwatch.GetTimestamp（）的值变化如此之大，以至于在一些类似形式的进一步计算中，它会导致溢出异常：
(Stopwatch.GetTimestamp() - ProgramStartStopwatchTimestamp) * n
其中n是一个大值，但足够小，如果秒表没有大幅跳动，那么程序可以运行数年而不会出现溢出异常。还要注意的是，这些异常发生在程序启动数小时后，因此问题不仅仅是Stopwatch在启动后立即向后运行了一点。它只是跳到了完全不同的范围，无论朝哪个方向。
关于秒表滚动，在上述情况之一中，它（不是差异，而是秒表）获得了某个值a la 0xFF4？？？？，所以它跳到了一个非常接近翻滚的范围。在多次重新启动程序后，这个新范围仍然持续有效。如果这再重要的话，考虑到无论如何都需要处理跳跃。。。
如果还需要确定时间戳取自哪个核心，那么了解执行核心的编号可能会有所帮助。为此，有称为GetCurrentProcessorNumber（自Server 2003和Vista起可用）和GetCurrentProcessorNumberEx（自Server 2008 R2和Windows 7起可用）的函数。有关更多选项（包括Windows XP），请参阅此问题的答案。
请注意，调度器可以随时更改核心编号。但是，当在读取Stopwatch时间戳之前和之后读取核心编号，并且核心编号保持不变时，也许可以假设Stopwatchs读取也在该核心上执行。。。
具体回答高级问题"Stopwatch.GetTimestamp()多久翻转一次&"；，微软的答案是：
距离最近一次系统启动不少于100年，根据使用的底层硬件计时器，可能会更长。对于大多数应用程序来说，滚动不是一个问题。