【问题标题】:.NET Lock Performance Counters Difference.NET 锁性能计数器差异
【发布时间】:2012-02-02 13:56:42
【问题描述】:

“.NET CLR LocksAndThreads”类别中的“争用总数”和“队列长度峰值”窗口性能计数器有什么区别? MSDN 文档可在此处获得:http://msdn.microsoft.com/en-us/library/zf749bat.aspx

我认为我的困惑在于“尝试获取锁失败的线程数”与“自应用程序启动以来等待获取托管锁的线程总数”之间的差异。从本质上讲,等待获取锁(我将其解释为在您尝试获取锁时有人持有它)与尝试获取锁未成功之间有什么区别?我能想到的唯一一件事与尝试获取锁的方式有关,例如Monitor.TryEnter 与 Monitor.Enter。

【问题讨论】:

  • 我认为他们测量的是不同的东西。争用是事件计数,队列长度是线程计数。也许 Contentions 是无法立即获取锁的次数,而 Queue Length 是无法立即获取锁的线程数。
  • 我感到困惑的是,当一个线程无法立即获取锁时,它如何不计入两个计数 - 换句话说,每个失败的锁获取都是线程失败的实例立即获取锁和未能立即获取锁的实例。有问题的应用程序的“队列长度峰值”值为 148,411,而“争用总数”仅为 255。
  • 我读到 Monitor 首先是作为自旋锁实现的,然后在一定时间后进入等待状态。也许一个计数器是自旋锁成功的次数,另一个是它失败的次数。我不知道;文档不清楚。
  • 这很有趣,我没有考虑过乐观的自旋锁定实现。您是否碰巧知道和/或有链接指向您在哪里发现有关 .NET 监视器实施的信息?
  • 这是我找到的one random blog entry。您可以随时反汇编 Monitor 类,并亲自查看它在做什么。

标签: .net windows performancecounter


【解决方案1】:

在尝试获取锁时,我会想到 3 种情况:
a) 资源未被其他实体锁定,立即获取
b) 资源被锁定,但按时释放,延迟获取
c) 资源被锁定,但未按时释放,获取超时

争用总数 - 方案总数 (c)
队列长度峰值 - 在任何给定时间处于状态 (b) 的线程最多

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-05-10
    • 1970-01-01
    • 2021-04-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-07-08
    相关资源
    最近更新 更多