关于threadlocal的来龙去脉

引用其他麻油的评论：

对TLS更简单的，但是更直观的理解可以如下（基于C语言）：

1. 全局对象，全局变量的作用域和生命周期是全局的，这里的全局是指进程范畴，也就是说，如果你将其设计为全局对象，全局变量，就意味着你希望在多线程的环境中，仍然能共享和访问。 全局对象，全局变量不是说不让多线程来访问，而是说有的时候不期望他们同时访问，此时引入了线程的互斥，互斥的后果是保证不同时访问，但是，并没有改变共享的本质！
--------------这里应该说的是synchronized
2. 如果设计的时候，就希望将某个对象，变量设计为线程局部的，那典型的是可以将其设计为函数的局部变量。 可是，我如果又希望在线程执行时，任意的函数和对象里面都可以访问到它那？！ 此时，可能会想到用全局对象，全局变量，但是，它又会使得这种访问域上升到进程级别，其实，我只是想在线程局部环境中，全局访问该对象。 此时TLS应运而生，TLS就是达到了这种， 在线程局部环境（或者称呼为线程执行环境，线程上下文）下可以全局访问的对象/变量。
------------这里应该说的是threadlocal了
关于TLS的实际应用，更多的是定义一个TLS对象来存储一些线程上下文相关的信息。

给你取这样一个典型的例子吧，你可以看到TLS实际的应用场合。

在一个支持单进程，多线程的轻量级移动平台中，假设我实现了一个APP Framework，每一个APP单独运行在一个独立的线程中，APP运行时关联了很多信息，比如打开的文件，引用的组件，启动的Timer等等。我希望框架能实现自动垃圾回收，什么概念，就会应用退出的时候，即便应用没有主动释放打开的文件句柄，没有主动cancel Timer，没有主动释放组件的引用，框架也可以自动完成这些收尾工作，否则，后果是不堪想象的。 

好了，假设应用的退出是调用了框架的 ExitApp API， 该API允许应用调用后关闭自己，也允许关闭别的应用。 那么，假设该API触发了应用的退出，最终调用到框架的App_CleanUp函数，那么App_CleanUp函数除了完成应用本身实例的释放外，肯定是在这里来完成我们上面说的收尾工作，怎么来做哪？！ 很明显，这里典型的，就可以使用TLS了。具体如下：

在Framework的API中，当应用的线程启动时，New 一个AppContext的对象或者结构体，然后将对象的指针或者结构体的指针以TLS的方式存储起来。 AppContext内部包含了文件句柄，timer引用，组件引用等等。 然后，后续任何框架的文件操作/Timer操作时，取当前线程的TLS，然后转换成AppContext后，将更新的文件句柄，timer引用等更新入AppContext对象内部。 然后，应用退出时，获取TLS，然后转换成AppContext，取出非空的文件句柄，组件引用，Timer引用等，来完成Cancel和Close操作。


其他不想说了，如果你能明白这个实际的例子，你就可以明白TLS的用途了。 上述的例子，来源于BREW/BMP框架内部的实际实现，当然有差别，但是思想是一样的