我是一个线程

来源于作者刘欣的《码农翻身》 + 自己的备注理解

我是一个线程， 我一出生就被编了个号： 0x3704, 然后被领到一个昏暗的屋子里， 这里我发现了很多和我一模一样的同伴。

线程一出生就有一个线程号，并且有自身的调用栈和数据，也维护了自己的寄存器（虚拟的）。

我身边的同伴0x6900 待的时间比较长， 他带着沧桑的口气对我说：
我们线程的宿命就是处理包裹。 把包裹处理完以后还得马上回到这里，否则可能永远回不来了。
我一脸懵懂，包裹，什么包裹？
”不要着急，马上你就会明白了， 我们这里是不养闲人的。“
果然，没多久，屋子的门开了， 一个面貌凶恶的家伙吼道：
＂0x3704 ,出来！＂
我一出来就被塞了一个沉甸甸的包裹，上面还有附带着一个写满了操作步骤的纸。
＂快去，把这个包裹处理了。＂
＂去哪儿处理＂
＂跟着指示走， 先到就绪车间＂

果然，地上有指示箭头，跟着它来到了一间明亮的大屋子，这里已经有不少线程了， 大家都很紧张，好像时刻准备着往前冲。
我刚一进来，就听见广播说：“0x3704, 进入车间”
我赶紧往前走， 身后很多人议论说：
”他太幸运了， 刚进入就绪状态就能运行“
”是不是有关系？“
”不是，你看人家的优先级多高啊， 唉“

进程状态

进程在其生命周期的三种状态： 运行状态，就绪状态， 阻塞状态。

前边就是车间， 这里简直是太美了， 怪不得老线程总是唠叨着说：要是能一直待在这里就好了。
这里空间大，视野好，空气清新，鸟语花香，还有很多从来没见过的人，像服务员一样等着为我服务。

他们也都有编号， 更重要的是每个人还有个标签，上面写着：硬盘，数据库，内存，网卡．．．

我现在理解不了，看看操作步骤吧：

第一步：从包裹中取出参数

打开包裹， 里边有个HttpRequest 对象, 可以取到 userName, password两个参数

第二步：执行登录操作

奥，原来是有人要登录啊，我把userName/password 交给 数据库服务员，他拿着数据， 慢腾腾的走了。
他怎么这么慢？　不过我是不是正好可以在车间里多待一会儿?　反正也没法执行第三步。

就在这时，车间里的广播响了：

"0x3704, 我是CPU , 记住你正在执行的步骤， 马上带包裹离开"

我慢腾腾的开始收拾

线程被调度到的时候享有一个时间片，事实上也是让cpu的计数器指向该线程所在的内存位置，然后执行操作。时间片用完，会进行线程切换，执行下一个线程。

”快点， 别的线程马上就要进来了“
离开这个车间， 又来到一个大屋子，这里很多线程慢腾腾的在喝茶，打牌。

”哥们，你们没事干了？“
”你新来的把， 你不知道我在等数据库服务员给我数据啊！ ，据说他们比我们慢好几十万倍， 在这里好好歇吧“
”啊？ 这么慢？ 我这里有人在登录系统， 能等这么长时间吗"
”放心，你没听说过人间一天， CPU一年吗， 我们这里是用纳秒，毫秒计时的， 人间等待一秒，相当于我们好几天呢， 来的及“

”听说了吗，最近有个线程被kill掉了“
”为啥啊？“
”这家伙赖在ＣＰＵ车间不走，　把CPU利用率一直搞成100%，后来就被kill掉了“
”Kill掉以后弄哪儿去了“
”可能被垃圾回收了吧“

我心里打了个寒噤 ， 赶紧接着处理， 收下的动作块多了，第二步登录成功了

线程可能要执行cpu密集型运算，有时候可能打满cpu，可以通过kill结束线程。

我正在紧张的制作html呢， CPU有开始叫了：
"0x3704, 我是CPU , 记住你正在执行的步骤， 马上带包裹离开"
”为啥啊“
”每个线程只能在CPU上运行一段时间，到了时间就得让别人用了， 你去就绪车间待着， 等着叫你吧“
就这样， 我一直在就绪-运行 这两个状态，不知道轮转了多少次， 终于安装步骤清单把工作做完了。
最后顺利的把包含html的包裹发了回去。

时间片

回到了小黑屋， 老线程0x6900 问：
”怎么样？第一天有什么感觉？“
”我们的世界规则很复杂 ， 首先你不知道什么时候会被挑中执行; 第二 ，在执行的过程中随时可能被打断，让出CPU车间;
第三，一旦出现硬盘，数据库这样耗时的操作也得让出CPU,去等待; 第四，就是数据来了，你也不一定马上执行，还得等着CPU挑选“

”小伙子理解的不错啊“
”我不明白为什么很多线程都执行完就死了， 为什么咱们还活着？“
”你还不知道， 长生不老是我们的特权， 我们这里有个正式的名称，叫做 线程池！“

线程池可以维护一个线程集合，避免线程运行完直接被回收，而是可以重新利用线程结构去执行其他命令，避免额外的创建开销。
数据库连接池也是类似的逻辑，在客户端维护与数据库的多个连接，避免了重复创建连接的开销（TCP连接）

我问线程池的元老0x6900 ： " 我们要工作到什么时候？"
" 要一直等到系统重启的那一刻"， 0x6900 说
" 那你经历过系统重启吗？"
" 怎么可能？ , 系统重启就是我们的死亡时刻， 也就是世界末日，一旦重启， 整个线程池全部销毁，时间和空间全部消失，一切从头再来”
" 那什么时候会重启？"
" 这就不好说了,好好享受眼前的生活吧....."

前几天我处理过一些从http 发来的存款和取款的包裹， 老线程0x6900 特意嘱咐我：
"处理这些包裹的时候要特别小心， 你得一定要先获得一把锁， 在对账户存款或者取款的时候一定要把账户给锁住， 要不然别的线程就会在你等待的时候趁虚而入，搞破坏， 我年轻那会儿很毛糙，就捅了篓子"

为了“恐吓”我， 好心的0x6900还给了我两个表格：

1、没有加锁的情况

没有加锁的情况

2、加锁的情况

加锁的情况

我看的胆颤心惊， 原来不加锁会带来这么严重的事故。
从此以后看到存款，取款的包裹就倍加小心， 还好，没有出过事故。

多线程执行时，为了避免切换过程中其他线程修改了共享区域的内存，往往需要进行加锁，避免对同一段内存，打开文件以及其他共享数据进行不安全的访问、（同一进程的线程共享进程的资源）

今天我收到的一个包裹是转账， 从某著名演员的账号给某著名导演赚钱， 具体是谁我就不透漏了， 数额可真是不小。
我按照老线程的吩咐， 肯定要加锁啊， 先对著名演员账号加锁， 在对著名导演账号加锁。
可我万万没想到的是， 还有一个线程，对，就是0x7954, 竟然同时在从这个导演到往这个演员转账。

于是乎，就出现了这么个情况：

死锁.png

刚开始我还不知道什么情况， 一直坐在等待车间傻等， 可是等的时间太长了， 长达几十秒 ！ 我可从来没有经历过这样的事件。
这时候我就看到了线程0x7954 , 他悠闲的坐在那里喝咖啡， 我和他聊了起来：
“哥们， 我看你已经喝了8杯咖啡了， 怎么还不去干活？”
“你不喝了9杯茶了吗？” 0x7954 回敬到。
“我在等一个锁， 不知道哪个孙子一直不释放”
“我也在等锁啊，我要是知道哪个孙子不释放锁我非揍死他不可 ” 0x7954 毫不示弱。

我偷偷的看了一眼， 这家伙怀里不就抱着我正在等的 某导演的锁嘛？

很明显， 0x7954 也发现了我正抱着他正在等待的锁。
很快我们两个就吵了起来，互不相让：
"把你的锁先给我， 让我先做完"
"不行， 从来都是做完工作才释放锁， 现在绝对不能给你"
从争吵到打起来， 就那么几秒钟的事儿。

更重要的是， 我们俩不仅仅持有这个著名导演和演员的锁， 还有很多其他的锁， 导致等待的线程越来越多， 围观的人们把屋子都挤满了。

最后事情真的闹大了， 我从来没见过终极大boss "操作系统" 也来了。

大Boss毕竟是见多识广， 他看了一眼， 哼了一声 ， 很不屑的说：
"又出现死锁了"
"你们俩要Kill掉一个， 来吧， 过来抽签 "
这一下子把我给吓尿了， 这么严重啊！
我战战兢兢的抽了签，打开一看， 是个"活"字。
唉，小命终于保住了。
可怜的0x7954 被迫交出了所有的资源以后， 很不幸的被kill掉， 消失了。
我拿到了导演的锁， 可以开始干活了。
大Boss操作系统如一阵风似的消失了， 身后只传来他的声音：
记住， 我们这里导演>演员， 无论认识情况都要先获得导演的锁
由于不仅仅是只有导演和演员， 还有很多其他人， Boss留下了一个表格， 里边是个算法， 用来计算资源的大小， 计算出来以后,永远按照从大到小的方式来获得锁：

image.png

我回到线程池， 大家都知道了我的历险， 围着我问个不停。

凶神恶煞的线程调度员把大Boss的算法贴到了墙上。

每天早上， 我们都得像无节操的房屋中介， 美容美发店的服务员一样， 站在门口，像被耍猴一样大声背诵：

"多个资源加锁要牢记， 一定要按Boss的算法比大小， 然后从最大的开始加锁"

死锁预防，可以使用线程id的hashcode进行比较，大的先访问，小的再访问