当前位置：网站首页>关于Signal Catcher线程中对线程的理解

关于Signal Catcher线程中对线程的理解

2022-04-21 14:51:00 【InfoQ】

首先简述下Signal Catcher，Signal Catcher线程接受到kernel系统底层的消息进行dump当前虚拟机的信息并且设置每个线程的标志位(check_point)和请求线程状态为挂起，当线程运行过程中进行上下文切换时会检查该标记。等到线程都挂起后，开始遍历Dump每个线程的堆栈和线程数据后再唤醒线程。关于ANR的更多内容在我的其他博客中进行
查阅~~
.

==本文重点讲的是在分析Singal Catcher时对线程有了更新的了解。==

在Android里面只能通过pthread_create去创建一个线程，Thread只是Android Runtime里面的一个类，一个Thread对象创建之后就会被保存在线程的TLS区域，所以一个Linux线程都对应了一个Thread对象，可以通过Thread的Current()函数来获取当前线程关联的Thread对象，通过这个Thread对象就可以获取一些重要信息，例如当前线程的Java线程状态，Java栈帧，JNI函数指针列表等等，之所以说是Java线程状态，Java栈帧，是因为Android运行时其实是没有自己单独的线程机制的，Java线程底层都是一个Linux线程，但是Linux线程是没有像Watting，Blocked等状态的，并且Linux线程也是没有Java堆栈的，那么这些线程状态和Java栈帧必须有一个地方保存，要不然就丢失了，Thread对象就是一个很理想的“储物柜”。

只有当创建出来的Thread对象执行了attach函数后，一个Linux线程在真正和虚拟机运行时关联起来，才变成了Java线程，才有了自己的java线程状态和java栈帧等数据结构，那些纯粹的native是不能执行java代码的，所以当系统发生crash或者anr进行dump进程的堆栈的时候，有些线程是没有java堆栈的，只有native和kernel堆栈，就是这个原因。那么这个attach()函数中做了哪些事情呢：

Thread* Thread::Attach(const char* thread_name, bool as_daemon, jobject thread_group,bool create_peer) {
 Runtime* runtime = Runtime::Current();
 ......
 Thread* self;
 {
 MutexLock mu(nullptr, *Locks::runtime_shutdown_lock_);
 if (runtime->IsShuttingDownLocked()) {
 ......
 } else {
 Runtime::Current()->StartThreadBirth();
 self = new Thread(as_daemon); //新建一个Thread对象
 bool init_success = self->Init(runtime->GetThreadList(), runtime->GetJavaVM()); //调用init函数
 Runtime::Current()->EndThreadBirth();
 if (!init_success) {
 delete self;
 return nullptr;
 }
 }
 }
 ......
 self->InitStringEntryPoints(); 
 CHECK_NE(self->GetState(), kRunnable);
 self->SetState(kNative);
 ......
 return self;
}

首先创建了一个Thread对象，接着执行了init()函数，然后在最后修改了线程的状态kNative(Java线程的状态是保存在Thread对象中的，具体来说是由对象中的tls32_这个结构体保存的，可以通过修改这个结构体来设置线程当前的状态：

inline ThreadState Thread::SetState(ThreadState new_state) {
 // Cannot use this code to change into Runnable as changing to Runnable should fail if
 // old_state_and_flags.suspend_request is true.
 DCHECK_NE(new_state, kRunnable);
 if (kIsDebugBuild && this != Thread::Current()) {
 std::string name;
 GetThreadName(name);
 LOG(FATAL) << &quot;Thread \&quot;&quot; << name << &quot;\&quot;(&quot; << this << &quot; != Thread::Current()=&quot;
 << Thread::Current() << &quot;) changing state to &quot; << new_state;
 }
 union StateAndFlags old_state_and_flags;
 old_state_and_flags.as_int = tls32_.state_and_flags.as_int;
 tls32_.state_and_flags.as_struct.state = new_state;
 return static_cast<ThreadState>(old_state_and_flags.as_struct.state);
}

enum ThreadState {
 // Thread.State JDWP state
 kTerminated = 66, // TERMINATED TS_ZOMBIE Thread.run has returned, but Thread* still around
 kRunnable, // RUNNABLE TS_RUNNING runnable
 kTimedWaiting, // TIMED_WAITING TS_WAIT in Object.wait() with a timeout
 kSleeping, // TIMED_WAITING TS_SLEEPING in Thread.sleep()
 kBlocked, // BLOCKED TS_MONITOR blocked on a monitor
 kWaiting, // WAITING TS_WAIT in Object.wait()
 kWaitingForGcToComplete, // WAITING TS_WAIT blocked waiting for GC
 kWaitingForCheckPointsToRun, // WAITING TS_WAIT GC waiting for checkpoints to run
 kWaitingPerformingGc, // WAITING TS_WAIT performing GC
 kWaitingForDebuggerSend, // WAITING TS_WAIT blocked waiting for events to be sent
 kWaitingForDebuggerToAttach, // WAITING TS_WAIT blocked waiting for debugger to attach
 kWaitingInMainDebuggerLoop, // WAITING TS_WAIT blocking/reading/processing debugger events
 kWaitingForDebuggerSuspension, // WAITING TS_WAIT waiting for debugger suspend all
 kWaitingForJniOnLoad, // WAITING TS_WAIT waiting for execution of dlopen and JNI on load code
 kWaitingForSignalCatcherOutput, // WAITING TS_WAIT waiting for signal catcher IO to complete
 kWaitingInMainSignalCatcherLoop, // WAITING TS_WAIT blocking/reading/processing signals
 kWaitingForDeoptimization, // WAITING TS_WAIT waiting for deoptimization suspend all
 kWaitingForMethodTracingStart, // WAITING TS_WAIT waiting for method tracing to start
 kWaitingForVisitObjects, // WAITING TS_WAIT waiting for visiting objects
 kWaitingForGetObjectsAllocated, // WAITING TS_WAIT waiting for getting the number of allocated objects
 kStarting, // NEW TS_WAIT native thread started, not yet ready to run managed code
 kNative, // RUNNABLE TS_RUNNING running in a JNI native method
 kSuspended, // RUNNABLE TS_RUNNING suspended by GC or debugger
};

这里主要分析init()函数，首先要先了解一下ART执行代码的方式，ART虚拟机和Dalvik最大的变化就是ART虚拟机==不在解释执行字节码，而是直接找到对应的机器码直接执行==。ART会在安装应用程序的时候执行dex2oat进程得到一个oat文件完成字节码翻译成本地机器码的工作，这个oat文件一般保存在/data/app/应用名称/oat/目录下，这个oat文件里面就是编译好的机器码，但是这些机器码不可能单独存在，需要借助于ART运行时（执行一个jni方法或者在heap中操作），这个可以类比于编译so库文件的时候引用到了外部函数（其实oat和so文件都是ELF可执行格式文件，只是oat文件相比于标准的ELF格式文件多出了几个section）。区别是打开标准的so文件的时候，一般用的是dlopen这个函数，该函数会把没有加载的so库加载进来，然后把这些外部函数重定位好；而oat文件为了快速加载，ART在==线程的TLS区域保存了一些函数==，编译好的机器码就是调用这些函数指针来和AT运行时建立联系，这些函数就是在Thread的init过程中初始化好的

版权声明
本文为[InfoQ]所创，转载请带上原文链接，感谢
https://xie.infoq.cn/article/1d603d71eaeac285d6ee6ee5d

边栏推荐

猜你喜欢

随机推荐