Android基础进阶 - 消息机制 之Native层分析，kotlin开源

value = sStrThreadlocal.get();
intValue = sIntegerThreadLocal.get();
System.out.println(“444 curThreadId=”+Thread.currentThread()+" strthreadLocalValue="+value
+" intThreadLocalValue="+intValue);

//用完之后记得remove，虽然，ThreadLocalMap.Entry的key是ThreadLocal的弱引用，但是value占用的内存空间还在。
//被回收的场景有两个，再次调用set或者get方法是会坚持map中是否有key为空的Entry（由于key是弱引用，外部强引用依赖断开后，gc时就会回收该key，
// 回收后即可null），如果有则清除。

//但是不知道什么时候再次调用set或者get，这种被动的方式只能说是做了个保证，如果没有调用set/get，就可能引发内存泄露
//ThreadLocal提供了一个remove方法，由我们主动清除ThreadLocal对应的ThreadLocalMap.Entry中的堆内存
sStrThreadlocal.remove();
sIntegerThreadLocal.remove();
value = sStrThreadlocal.get();
intValue = sIntegerThreadLocal.get();
System.out.println(“after remove 444 curThreadId=”+Thread.currentThread()+" strthreadLocalValue="+value
+" intThreadLocalValue="+intValue);
}
}

对应的输出为

111 curThreadId=Thread[main,5,main] strthreadLocalValue=aaa intThreadLocalValue=1
444 curThreadId=Thread[main,5,main] strthreadLocalValue=aaa intThreadLocalValue=1
after remove 444 curThreadId=Thread[main,5,main] strthreadLocalValue=null intThreadLocalValue=null

下面开始本篇的分析学习

我们在前面两篇关于Android消息机制的分析学习中了解到MessageQueue中涉及到何Native的交互，比如nativeInit初始化Native层的MessageQueue；nativePollOnce阻塞；nativeWake唤醒。

问题是，为什么要这样设计？直接Java层不是一样可以管理维护消息队列以及消息的读取分发吗？nativePollOnce真正的意义是什么？这个问题一致困挠着我。通过反复查资料翻源码，终于了解了其流程。在消息机制Native层实现之前我们先了解下其中用到的一些Linux基础知识。否则的话，很容易被卡住。

一、 基础知识简介

1.1 Linux eventfd事件等待/响应机制

Linux常用的进程/线程间通信机制有管道、信号量、消息队列、信号、共享内存、socket等等，其中主要作为进程/线程间通知/等待的有管道pipe和socket。从Linux 2.6.27版本开始增加了eventfd，主要用于进程或者线程间的通信，eventfd用于进程/线程间通信，效率比pipe高.

1.2 Linux IO多路复用epoll

epoll是Linux中最高效的IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作

epoll有3个方法，epoll_create()， epoll_ctl()，epoll_wait()_

** epoll_create :创建epoll句柄**

int epoll_create(int size)；
：用于创建一个epoll的句柄，size是指监听的描述符个数， 现在内核支持动态扩展，该值的意义仅仅是初次分配的fd个数，后面空间不够时会动态扩容。 当创建完epoll句柄后，占用一个fd值.

使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

** epoll_ctl：执行对需要监听的文件描述符(fd)的操作**

int epoll_ctl(int epfd, int op, int fd, struct ep