托管对象本质-第二部分-对象头布局和锁成本

2019/04/10 10:10
阅读数 8

托管对象本质-第二部分-对象头布局和锁成本

原文地址:https://devblogs.microsoft.com/premier-developer/managed-object-internals-part-2-object-header-layout-and-the-cost-of-locking/ 原文作者:Sergey 译文作者:杰哥很忙

目录

托管对象本质1-布局 托管对象本质2-对象头布局和锁成本 托管对象本质3-托管数组结构 托管对象本质4-字段布局

我从事当前项目时遇到了一个非常有趣的情况。对于给定类型的每个对象,我必须创建一个始终增长的标识符,但需要注意: 1) 该解决方案可以在多线程环境中工作 2) 对象的数量相当大,多达千万。 3) 标识应该按需创建,因为不是每个对象都需要它。

在最初的实现过程中,我还没有意识到应用程序将处理的数量,因此我提出了一个非常简单的解决方案:

public class Node
{
    public const int InvalidId = -1;
    private static int s_idCounter;
 
    private int m_id;
 
    public int Id
    {
        get
        {
            if (m_id == InvalidId)
            {
                lock (this)
                {
                    if (m_id == InvalidId)
                    {
                        m_id = Interlocked.Increment(ref s_idCounter);
                    }
                }
            }
 
            return m_id;
        }
    }
}

代码使用双重检查的锁模式,允许在多线程环境中初始化标识字段。在其中一个分析会话中,我注意到具有有效 ID 的对象数量达到数百万个实例,主要令我惊讶的是,它并没有在性能方面引起任何问题。

之后,我创建了一个基准测试,以查看与无锁定方法相比,锁语句在性能方面的影响。

public class NoLockNode
{
    public const int InvalidId = -1;
    private static int s_idCounter;
 
    private int m_id = InvalidId;
 
    public int Id
    {
        get
        {
            if (m_id == InvalidId)
            {
                // Leaving double check to have the same amount of computation here
                if (m_id == InvalidId)
                {
                    m_id = Interlocked.Increment(ref s_idCounter);
                }
            }
 
            return m_id;
        }
    }

为了分析性能差异,我将使用基准DotNet

List<NodeWithLock.Node> m_nodeWithLocks => 
    Enumerable.Range(1, Count).Select(n => new NodeWithLock.Node()).ToList();
List<NodeNoLock.NoLockNode> m_nodeWithNoLocks => 
    Enumerable.Range(1, Count).Select(n => new NodeNoLock.NoLockNode()).ToList();
 
[Benchmark]
public long NodeWithLock()
{
    // m_nodeWithLocks has 5 million instances
    return m_nodeWithLocks
        .AsParallel()
        .WithDegreeOfParallelism(16)
        .Select(n => (long)n.Id).Sum();
}
 
[Benchmark]
public long NodeWithNoLock()
{
    // m_nodeWithNoLocks has 5 million instances
    return m_nodeWithNoLocks
        .AsParallel()
        .WithDegreeOfParallelism(16)
        .Select(n => (long)n.Id).Sum();
}

在这种情况下,NoLockNode 不适合多线程方案,但我们的基准测试也不会尝试同时从不同的线程获取两个实例的 Id。当争用很少发生时,基准测试模拟了真实场景,在大多数情况下,应用程序只是使用已创建的标识符。

Method 平均值 标准差
NodeWithLock 152.2947 ms 1.4895 ms
NodeWithNoLock 149.5015 ms 2.7289 ms

我们可以看到,差别非常小。CLR 是如何做到获得 100 万个锁而几乎无开销呢?

为了阐明 CLR 行为,让我们用另一个案例来扩展我们的基准测试套件。我们添加另一个Node类,该类在构造函数中调用 GetHashCode 方法(其非重写版本),然后丢弃结果:

public class Node
{
    public const int InvalidId = -1;
    private static int s_idCounter;
    private object syncRoot = new object();
    private int m_id = InvalidId;
    public Node()
    {
        GetHashCode();
    }
 
    public int Id
    {
        get
        {
            if (m_id == InvalidId)
            {
                lock(this)
                {
                    if (m_id == InvalidId)
                    {
                        m_id = Interlocked.Increment(ref s_idCounter);
                    }
                }
            }
 
            return m_id;
        }
    }
}
Method 平均值 标准差
NodeWithLock 152.2947 ms 1.4895 ms
NodeWithNoLock 149.5015 ms 2.7289 ms
NodeWithLockAndGetHashCode 541.6314 ms 4.0445 ms

GetHashCode调用的结果被丢弃,调用本身不会影响整体的测试时间,因为基准从测量中排除了构造时间。但问题是:有在NodeWithLock这个例子中,为什么锁语句的开销几乎为0,而在NodeWithLockAndGetHashCode中对象实例调用GetHashCode方法时,开销明险不同?

轻量锁、锁膨胀和对象头布局

CLR 中的每个对象都可用于创建关键区域以实现互斥执行。你可能会认为,为了做到这一点,CLR为每个CLR对象创建一个内核对象。但是,这种方法没有意义,因为只有很小一部分对象用作同步的句柄。因此,CLR 按需创建同步所需的重量级的数据结构非常有意义。此外,如果 CLR 不需要冗余数据结构,就不会创建它们。

如你所知,每个托管对象都有一个称为对象头的辅助字段。对象头本身可用于不同的目的,并且可以根据当前对象的状态保留不同的信息。

CLR 可以同时存储对象的哈希代码、领域特定信息、与锁相关的数据以及和一些其他内容。显然,4 个字节的对象头根本不足以满足所有这些功能。因此,CLR 将创建一个称为同步块表的辅助数据结构,并且只在对象头本身中保留一个索引。但是 CLR 会尽量避免这种情况,并尝试在标头本身中放置尽可能多的数据。

下面是对象头最重要的字节的布局:

如果BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX位为 0,则头本身保留所有与锁相关的信息,锁称为"轻量锁"。在这种情况下,对象头的总体布局如下:

如果BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX位为 1,为对象创建的同步块或计算哈希代码。如果BIT_SBLK_IS_HASHCODE为 1(第26位),则双字其余部分(0 ~ 25位)是对象的哈希代码,否则,0 ~ 25位表示同步块索引:

译者补充:1字=2字节,双字即为4字节 双字的其余部分说的就是对象头4字节低于26位的部分。上一节我们说了即使64位对象头是8字节,实际也只是用了4个字节。

我们可以使用 WinDbg 和 SoS 扩展来研究轻量锁。首先,我们对一个简单对象的锁语句中停止执行,这不会调用 GetHashCode 方法:

object o = new object();
lock (o)
{
    Debugger.Break();
}

在 WinDbg 中,我们将运行 .loadby sos clr 来加载 SOS 调试扩展,然后运行两个命令:DumpHeap -thinlock 查看所有轻量锁, DumpObj obj 查看我们在锁语句中使用实例的状态:

0:000> !DumpHeap -thinlock
Address MT Size
02d223e0 725c2104 12 ThinLock owner 1 (00ea5498) Recursive 0
Found 1 objects.
0:000> !DumpObj /d 02d223e0
Name: System.Object
MethodTable: 725c2104
ThinLock owner 1 (00ea5498), Recursive 0 

至少有两种情况可以将轻量锁升级为"重量锁": (1) 另一个线程的同步根上的争用,需要创建内核对象; (2) CLR 无法将所有信息保留在对象标头中,例如,对 GetHashCode 方法的调用。

CLR 监视器实现了一种"混合锁",在创建真正的 Win32 内核对象之前尝试先自旋。以下是来自 Joe Duffy 的《Windows并发编程》中的监视器的简短描述:"在单 CPU 计算机上,监视器实现将执行缩减的旋转等待:当前线程的时间片通过在等待之前调用 SwitchToThread 切换到调度器。在多 CPU 计算机上,监视器每隔一段时间就会产生一个线程,但是在返回到某个线程之前,繁忙的线程会旋转一段时间,使用指数后退方案来控制它重新读取锁状态的频率。所有这一切都是为了在英特尔超线程计算机上正常工作。如果在固定旋转等待期用完后锁仍然不可用,就会尝试将回退到使用基础 Win32 事件的真实等待。我们讨论一下它是如何工作的。

译者补充: CLR使用的是混合锁,先尝试使用轻量锁,若锁长时间被占用,自旋带来的开销会大于用户态到内核态转换带来的开销,此时就会尝试使用重量锁。 译者补充: 换句直白的话来说,单线程下在未获取待锁等待之前,会尝试切换到其他线程,而在多线程下使用锁时,首先会尝试用自旋锁,而自旋的时间以指数变化上升,若最终仍然没有获取到,则会调用实际的win32 内核模式的真实等待时间。

我们可以检查,在这两种情况下,锁膨胀确实发生,一个轻量锁被升级为重量锁:

object o = new object();
// Just need to call GetHashCode and discard the result
o.GetHashCode();
lock (o)
{
    Debugger.Break();
}
0:000> !dumpheap -thinlock
Address MT Size
Found 0 objects.
0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
1 011790a4 1 1 01155498 4ea8 0 02db23e0 System.Object 

正如您所看到的,只需在同步对象上调用 GetHashCode,我们将获得不同的结果。现在没有轻量锁,同步根具有与其关联的同步块。

如果其他线程长时间占用锁,我们可以得到相同的结果:

object o = new object();
lock (o)
{
    Task.Run(() =>
    {
        // 线程征用轻量级锁
        lock (o) { }
    });
 
    // 10 ms 不够,CLR 自旋会超过10ms.
    Thread.Sleep(100);
    Debugger.Break();
}

在这种情况下,会有一样的结果:轻量锁会升级同时会创建同步块。

0:000> !dumpheap -thinlock
Address MT Size
Found 0 objects.
0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
6 00d9b378 3 1 00d75498 1884 0 02b323ec System.Object 

结论

现在,基准输出应该更容易理解。如果 CLR 可以使用轻量锁,则可以获取数百万个锁,而开销几乎为0。轻量锁非常高效。要获取锁,CLR 将更改对象头中的几个位用来存储线程 ID,等待线程将旋转,直到这些位变为非零。另一方面,如果轻量锁被升级为"重量锁",开销会变得更加明显。特别是当获得重量锁的对象数量相当大时。


20191127212134.png 微信扫一扫二维码关注订阅号杰哥技术分享 出处:https://www.cnblogs.com/Jack-Blog/p/12259258.html 作者:杰哥很忙 本文使用「CC BY 4.0」创作共享协议。欢迎转载,请在明显位置给出出处及链接。

原文出处:https://www.cnblogs.com/Jack-Blog/p/12259258.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部