线程列表锁上的锁争用

huangapple go评论77阅读模式
英文:

Lock contention on thread list lock

问题

在使用Perfetto工具分析我的Android应用时,我发现了许多线程锁定的情况,其中包含消息"Lock contention on thread list lock (owner tid: ...)"。

典型的Perfetto截图:

线程列表锁上的锁争用

线程列表锁上的锁争用

是什么导致了这个锁定?哪些代码调用可能会触发这样的锁定?

英文:

During profiling my Android application using Perfetto tool I've found many cases with thread locking with message "Lock contention on thread list lock (owner tid: ...)"

Typical Perfetto screenshot:

线程列表锁上的锁争用

线程列表锁上的锁争用

What is the cause of the lock? Which code calls can trigger such locks?

答案1

得分: 1

很遗憾,这种上下文(包括类/行号)无法获取,因为系统没有提供。目前,这需要手动检查跟踪并猜测可能是问题的锁。

这在将来的Android版本中可能会得到改善,但这并不一定会在今天帮助您。

英文:

Unfortunately such context (down to the class/line number) is not available as the system does not provide it. Currently this requires inspecting the trace manually and making guesses on which lock might be the problem.

This may be improved in future versions of Android but that doesn't necessarily help you today.

答案2

得分: 1

锁的原因是什么?哪些代码调用可能会触发这种锁定?

这个锁用于管理对ART(Android JVM)内部线程列表的独占访问

ART在内部的许多地方都使用了它。其中一些(比如创建/销毁线程或收集堆栈跟踪)可以直接由您的代码引发。有些(比如垃圾回收)会自动发生。甚至有一些是由于您正在收集跟踪信息引起的(https://cs.android.com/android/platform/superproject/main/+/refs/heads/main:art/runtime/monitor.cc;l=469;drc=ee5f2cb7e77baf63f79fb7c1fb8caecf1b5e7956)。这些示例远非详尽无遗。

您应该担心吗?很难从这个非常放大的截图中说出来,需要非常频繁地发生才能成为实际问题,因为42微秒是非常短的时间(约为1/23800秒)。

如果最终证明是实际问题...通常来说,尝试限制您的代码的“全局效应”(垃圾创建、线程创建/退出/中断、监视器使用等)可能会有所帮助,但最精确的方法是添加自己的跟踪来尝试准确定位触发它的确切操作。记得检查阻塞器和被阻塞者。

英文:

> What is the cause of the lock? Which code calls can trigger such locks?

The lock is used to manage exclusive access to ART's (the Android JVM's) internal thread list.

ART uses it in lots of places internally. Some of them (like creating/destroying threads or collecting stack traces) can be directly caused by your code. Some (like garbage collection) happen automatically. Some are even caused by the fact that you're collecting a trace. And these examples are far from exhaustive.

Should you worry about it? It's hard to say from this very zoomed-in screenshot without the larger context. 42µs is a very short time (about 1/23800th of a second), so it'd need to happen very frequently to become an actual problem.

If it turns out to be an actual problem... Generally, trying to limit your code's "global effects" (garbage creation, thread creation/exiting/interrupts, monitor usage, etc) would probably help, but the most precise way would be to add your own tracing to try to pinpoint what exactly you're doing to trigger it. Remember to check both the blocker and the blockee.

huangapple
  • 本文由 发表于 2023年7月17日 21:58:16
  • 转载请务必保留本文链接:https://go.coder-hub.com/76705195.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定