list_lock以及内存分配区锁导致进程虚拟内存耗尽的问题分析

本文分析了glibc中由于atfork时的list_lock和分配区锁导致的进程虚拟内存耗尽问题。在创建线程时,线程可能会在尝试获取分配区锁失败后,由于list_lock的释放,误创建新的分配区,而非重试加锁。这可能导致分配区数量远超实际线程数,引发内存问题。
摘要由CSDN通过智能技术生成
由于在atfork时,父线程(进程)会对所有的分配区加锁,并对全局锁list_lock加锁,在有线程在创建子线程的情况下,当前线程是不能获得分配区的,所以在没有重试的情况下,先尝试获得全局锁list_lock,如果不能获得全局锁list_lock,阻塞在全局锁list_lock上,直到获得全局锁list_lock,也就是说当前已没有线程在创建子线程,然后再重新遍历全局分配区链表,尝试对分配区加锁,如果经过第二次尝试仍然未能获得一个分配区,只能创建一个新的非主分配区了。
当进程在创建线程时会调用ptmalloc_lock_all()函数对 list_lock 以及所有内存分配区加锁:

static void
ptmalloc_lock_all (void)
{
  mstate ar_ptr;

  if(__malloc_initialized < 1)
    return;
  if (mutex_trylock(&list_lock))//获取锁返回0
    {
      Void_t *my_arena;
      tsd_getspecific(arena_key, my_arena);
      if (my_arena == ATFORK_ARENA_PTR)
    /* This is the same thread which already locks the global list.
       Just bump the counter.  */
    goto out;

      /* This thread has to wait its turn.  */
       (void)mutex_lock(&list_lock);
    }
  for(ar_ptr = &main_arena;;) {//对所有分配区加锁
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值