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