工控智汇

工控智汇

终于有大佬把"计算机底层原理"全部总结出来了

admin 123 197
计算机的历史算盘和机械计算机

有很多民族自豪感爆棚的兄弟会把算盘当成计算机的起源,还有爆破天的兄弟会把阴阳当成二进制0和1的起源,我觉得这件事儿就有点儿不靠谱了

如果非要追究计算机的鼻祖,那就得讲讲17世纪前欧洲的故事,最早的计算机其实是计算器,就是算数用的,在欧洲工业工业革命的时候,大量的工业模具需要计算,欧洲又没有中国传统的计算器-算盘,就催生了很多科学家发明自己的计算器(对,就是计算器,就是以前菜市场还在使用的那种,还不能称之为现在的计算机),这其中有个NB的人物,这个人叫布莱士帕斯卡,我们的压强单位(帕,千帕,百帕,兆帕)等等,就是以这哥们儿的名字命名,还有,计算机语言里面有一种叫做Pascal,就是为了纪念他。


就是这么个NB的人物,发明了最早的机械计算器,长这样儿:


经过后人的逐步改进,机械计算机的最后发展堪称精美,有长这样儿的:


还有长成这样儿的:


还有更NB的:


机械计算机改进者中有个人值得一提,他就是德国百科全书式的天才,17世纪的亚里士多德--莱布尼茨!


莱伯尼兹这个人又是个大牛,他既懂物理又懂数学(物理数学不分家),著名的微积分基本定理,牛顿莱布尼茨公式,就是莱布尼茨发明的,当然这里面是牛顿跟莱布尼茨或者说英国跟欧洲大陆的恩怨情仇。简单说,莱布尼茨发表论文创立微积分公式,牛顿当时是英国皇家学会的老大,话语权影响力比较大。牛顿说莱布尼茨发表的公式是参考了牛顿三年前的笔记,莱布尼茨嗓门不够响,争不过牛顿,所以没有办法,后人就把这个公式称为牛顿莱布尼茨公式。

一个人想在社会取得回报或者想发挥巨大作用,就必须要明白这个社会的运行机制,通过这件事儿,大家应该明白话语权的(传媒、笔杆子)重要性,如果还不能理解,参考美国把上个世纪的美国病毒命名为西班牙病毒这件事儿,当然最近又想把新冠病毒扣在我们脑袋上,就是因为他把控了话语权。衍生出来你应该明白的是,历史是个任人打扮的小姑娘,你看到的,你听到的,都是别人想让你看到和听到的,所以你要进行深度的思考,他是谁?为什么这么说?他说的是真的吗?对我有没有什么企图?多问自己几个为什么,你会慢慢从白痴成为智者。

扯远了,还说回来莱布尼茨,他除了改进机械计算机以外,还有一个重要的发明,那就是大名鼎鼎的二进制!(这里终于跟现代IT技术关联起来了)据说二进制的发明是参考中国古代的阴阳太极图而创作出来的,对此,我觉得倒是真的有可能。因为莱布尼茨有一本著名的著作,叫做《论中国人的自然哲学》,说明这个人对中国是有研究的。而且,他发明了二进制以后,还通知了当时的康熙大帝,因为他认为康熙大帝是个数学迷(对此我深表怀疑)。

当然,机械计算机又大又笨重,早就被现代的电子计算机所取代,不过说句题外话,机械计算机也有电子计算机所不具备的优点,就是结实耐用,几百年都不坏,而且,还不用电,谁要是大学食堂里面打饭收费做计算的时候来这么一台,那绝对是学妹眼中最酷的仔!

顺便也来一张现代电子计算机的鼻祖(当然,第一台电子计算机这件事儿也是见仁见智,美国嗓门大,所以现在资料大多认为1946诞生于美国宾夕法尼亚大学的“ENIAC”是世界上第一台电子计算机),它长这样儿:


这是个庞然大物,它大概占地一个别墅,跟一辆前苏联虎式坦克一样重,每个小时耗电150度,但是,每秒钟的计算量仅区区的5000次,要知道现在手机上的芯片的计算速度可以达到每秒10000000000000次。不过就是这样一台还比上菜市场计算器的东西,开启了20世纪最NB的数字化革命!从此之后,计算机行业飞速发展,造就了现在所谓的信息化大革命。

严格讲,这台机器应该称作电子管计算机,因为,这里面用的零件全部都是电子管,电子管如果开关的速度太快,很容易就会坏掉,据说这台机器每天都会有电子管冒烟儿,工程师在寻找和修复每一个电子管中疲于奔命,想象一天24小时,计算时间仅有半小时,剩下的23个半小时都是在寻找和修复坏掉的点,这是多么让人抓狂的一件事。如果你不能理解这件事儿,想象一下一个灯泡每秒不停地开关5000次,它会不会坏掉。而且,电子管还有很严重的发热问题,需要把风扇进行紧密的排布,这也是一个工艺难题。

不过,幸运的是,在这台又笨重毛病又多的计算机问世的第二年,也就是1947年,美国贝尔实验室研究发明了晶体管,和电子管相比,晶体管体积又小,耗电还低,最重要每秒开关几十万上亿次都不带坏的,从这一刻开始,计算机革命才真正的进入了突飞猛进的时代。

这堂课,我们要讲的就是计算机的原理。

CPU的原理

为什么讲线程要讲CPU?因为线程和CPU有一对一的对应关系!(超线程除外)

当然,现代的计算机的核心,也就是芯片,是由1000000000零件构成,我没有办法带你走遍这里面的每一个细节,不过,作为高级语言的程序员,我会带你走到足够深的深度,让你能够深入理解你写的每一行代码到底在计算机内部是怎么转换成电信号,从而被精密执行的。这一点很重要,因为这会给你带来“通透感”(原谅我找不到更好的形容词,现在很多程序员是没有经过科班训练的,是根据业务进行速成的,对这样的小伙伴儿来说,你写的代码虽然可以工作,但是它对你是一个黑盒子,你看不到代码背后的一切,从而也就无法进行更深入的理解和更准确的调优,总之,我个人非常喜欢这种通透感,我不喜欢一个技术对我来说是黑盒,是秘密,希望你也能理解和享受这种通透感)

好吧,让我们揭开代码背后的神秘世界吧。

还要从一个故事谈起。

我小时候最喜欢的女同学叫小芳,长得好看又善良,我们俩情投意合,每天放学后都约会共同进步,童年的时候山青水白,鸟语花香,环境特别好,我们的年纪都很小,我爱谈天她爱笑,有一回并肩坐在桃树下,风在林梢鸟在叫,不知怎么就睡着了,梦里花落知多少

不要打断我,让我陷在美好的回忆中不可自拔一会儿。

只不过后来大人发现了我们的联系,用他们自带的污秽的思想,认为我们的关系是污秽的,是不纯洁的,我们当时还没有罗密欧与朱丽叶,梁山伯与祝英台这样的觉悟,不懂得以死相争,所以就被双方家长棒打鸳鸯,各自关了禁闭。

不过这个难不倒刚刚学了电学的我,我们就设立了这样入门级别的电路:


我还发明了灯泡语言:

亮亮=放

亮灭=学

灭亮=等

灭灭=我

当然你会发现如果只有两个信号的组合,就最多表示四个字,如果想沟通更顺畅,我只要增加信号的组合长度就可以了,比如三个信号,我就可以表示八个字

亮亮亮=放

亮亮灭=学

亮灭亮=等

亮灭灭=我

灭灭亮=一

灭灭灭=起

灭亮灭=电

灭亮亮=影

如果想交流的更加复杂,我可以增加更长的信号组合,比如我如果用16个长度的信号,就可以表示2^16个汉字,这个数字是65536,要知道,我们日常的汉字常用的话也就4000个左右,整个康熙字典的总字数也仅仅47000个,我用灯泡信号的长度仅需要16个信号长,就足矣涵盖中文的交流了。

思考题:如果仅需要覆盖日常交流(4000个汉字),我需要的信号组合的长度至少是多少?

灯泡语言有些复杂,我结合莱布尼茨的二进制,用1来代表灯泡亮(通电),用0来代表灯泡灭(断电),这样我和小芳就有了自己的通信语言,比如下面这句话,你猜我说了什么?

111110001000=(?)把答案写到括号里。

话说到这里,不知道大家有没有发现,我发明了一种汉字编码,就是把特定的汉字用0和1的组合表示出来,注意,汉字的编码并不是只有一种方式,完全有可能发生的是,在一种的编码方式中,111代表'我',而在另外一种编码方式中111代表'中',如果我们在解析一段编码的用错了编码格式,就会出现平时经常遇见的'乱码'问题。

思考题:A编码中,111=我110=你,B编码中111=沙110=雕,那么下面这段话究竟代表什么呢?
110111110

再有了第一个电路的基础之上,我有设计了下面的电路:


这里就有了输入和输出的概念了

输入1

输入2

输出

0

0

0

0

1

0

1

0

0

1

1

1

可以用这样的符号表示:


也可以有这样的电路:




加法器

输入1

输入2

加和输出

进位输出

0

0

0

0

0

1

1

0

1

0

1

0

1

1

0

1







时钟


ram保存信号


程序-自动化(时钟信号+

荐书

《编码隐匿在计算机软硬件背后的语言》《Code:TheHiddenLanguageofComputerHardwareandSoftware》

程序的执行

进程与线程

一个程序,读入内存,全是0和1构成

从内存读入到CPU计算,这个时候要通过总线

怎么区分一段01的数据到底是数据还是指令?

总线分类为三种:控制线地址线数据线

一个程序的执行,首先把可执行文件放到内存,找到起始(main)的地址,逐步读出指令和数据,进行计算并写回到内存。

什么是进程?什么是线程?

一个程序进入内存,被称之为进程?一个可以运行多份儿吗?

同一个进程内部:有多个任务并发执行的需求(比如,一边计算,一边接收网络数据,一边刷新界面)

能不能用多进程?可以,但是毛病多,最严重的毛病是,我可以很轻易的搞死别的进程

线程的概念横空出世:共享空间,不共享计算

进程是静态的概念:程序进入内存,分配对应资源:内存空间,进程进入内存,同时产生一个主线程

线程是动态的概念:是可执行的计算单元(任务)

一个ALU同一个时间只能执行一个线程

同一段代码为什么可以被多个线程执行?

线程的切换

保存上下文,保存现场

问题:是不是线程数量越多,执行效率越高?(初级)
展开:调度算法怎么选?(难)

问题:单核CPU多线程执行有没有意义?(初级)

问题:对于一个程序,设置多少个线程合适?(线程池设定多少核心线程?)(中高级)

线程调度器算法(平均时间片、CFS(考虑权重))

CPU的并发控制关中断缓存一致性协议

CPU的速度和内存的速度(100:1)

这里的速度值得是ALU访问寄存器的速度比访问内存的速度快100倍

为了充分利用CPU的计算能力,在CPU和内存中间引入缓存的概念(工业上的妥协,考虑性价比)

现在的工业实践,多采用三级缓存的架构

缓存行:一次性读取的数据块

程序的局部性原理:空间局部性时间局部性

如果缓存行大:命中率高,但读取效率低。如果缓存行小:命中率低,但读取效率高。

工业实践的妥协结果,目前(2021)的计算机多采用64bytes(64*8bit)为一行

由于缓存行的存在,我们必须有一种机制,来保证缓存数据的一致性,这种机制被称为缓存一致性协议。

系统屏障

程序真的是按照“顺序”执行的吗?

CPU的乱序执行

Disorder这个程序,证明乱序执行的确存在

为什么会乱序?主要是为了提高效率(在等待费时的指令执行的时候,优先执行后面的指令)

线程的as-if-serial

单个线程,两条语句,未必是按顺序执行

单线程的重排序,必须保证最终一致性

as-if-serial:看上去像是序列化(单线程)

会产生的后果

多线程会产生不希望看到的结果

ThisEscape(this溢出问题)

推荐《EffectiveJava》-不要在构造方法中启动线程!

哪些指令可以互换顺序

hanppens-before原则(JVM规定重排序必须遵守的规则)

(不需要记住)

•程序次序规则:同一个线程内,按照代码出现的顺序,前面的代码先行于后面的代码,准确的说是控制流顺序,因为要考虑到分支和循环结构。

•管程锁定规则:一个unlock操作先行发生于后面(时间上)对同一个锁的lock操作。

•volatile变量规则:对一个volatile变量的写操作先行发生于后面(时间上)对这个变量的读操作。

•线程启动规则:Thread的start()方法先行发生于这个线程的每一个操作。

•线程终止规则:线程的所有操作都先行于此线程的终止检测。可以通过()方法结束、()的返回值等手段检测线程的终止。

•线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生,可以通过()方法检测线程是否中断

•对象终结规则:一个对象的初始化完成先行于发生它的finalize()方法的开始。

•传递性:如果操作A先行于操作B,操作B先行于操作C,那么操作A先行于操作C

禁止编译器乱序使用内存屏障阻止指令乱序执行

内存屏障是特殊指令:看到这种指令,前面的必须执行完,后面的才能执行

intel:lfencesfencemfence(CPU特有指令)

JVM中的内存屏障

所有实现JVM规范的虚拟机,必须实现四个屏障

LoadLoadBarrierLoadStoreSLSS

volatile的底层实现

volatile修饰的内存,不可以重排序,对volatile修饰变量的读写访问,都不可以换顺序

1:volatilei

2:ACC_VOLATILE

3:JVM的内存屏障

屏障两边的指令不可以重排!保障有序!

as-if-serial
4:hotspot实现

intfield_offset=cache-f2_as_index();if(cache-is_volatile()){if(support_IRIW_for_not_multiple_copy_atomic_cpu){OrderAccess::fence();}

orderaccess_linux_

inlinevoidOrderAccess::fence(){if(os::is_MP()){//alwaysuselockedaddlsincemfenceissometimesexpensiveelse__asm__volatile("lock;addl$0,0(%%esp)":::"cc","memory");defineLOCK_IF_MP(mp)"cmp$0,"#mp";je1f;lock;1:"

最终实现:

cmpxchg=cas修改变量值

lockcmpxchg指令

硬件:

lock指令在执行的时候视情况采用缓存锁或者总线锁

两种锁的效率

不同的场景:

临界区执行时间比较长,等的人很多-重量级

时间短,等的人少-自旋锁

synchronized如何保障可见性

JVM中的线程和OS线程对应关系

JVM1:1-LOOM-M:N(golang)

synchronized锁升级过程

(内容太多,见另一篇文档)

常见的锁类型

悲观锁乐观锁

自旋锁(CAS)

读写锁

排他锁共享锁

分段锁

死锁活锁

数据库的行锁表锁间隙锁

偏向锁

可重入锁

题外话:有没有程序天生就是线程安全的?

有没有一门编程语言天生安全,目前有一门RUST,但是由于语言难度较大,同时缺乏强有力的团队推广,目前并不是很流行,对RUST有了解兴趣的,参考马士兵老师《RUST》

一些大厂难题线程唤醒问题(阿里)样例代码
publicclassTest{/***有三个线程A,B,C*A为什么总是在C前面抢到锁???*/privatefinalstaticObjectLOCK=newObject();publicvoidstartThreadA(){newThread(()-{synchronized(LOCK){(().getName()+":getlock");//启动线程bstartThreadB();(().getName()+":startwait");try{//线程();}catch(InterruptedExceptione){();}(().getName()+":getlockafterwait");(().getName()+":releaselock");}},"thread-A").start();}privatevoidstartThreadB(){newThread(()-{synchronized(LOCK){(().getName()+":getlock");//启动线程cstartThreadC();try{(500);}catch(InterruptedExceptione){();}(().getName()+":startnotify");//线程b唤醒其他线程();(().getName()+":releaselock");}},"thread-B").start();}privatevoidstartThreadC(){newThread(()-{(().getName()+":threadcstart");synchronized(LOCK){(().getName()+":getlock");(().getName()+":releaselock");}},"thread-C").start();}publicstaticvoidmain(String[]args){newTest().startThreadA();}}
输出结果:
thread-A:getlockthread-A:startwaitthread-B:getlockthread-C:threadcstartthread-B:startnotifythread-B:releaselockthread-A:getlockafterwaitthread-A:releaselockthread-C:getlockthread-C:releaselock
问题:

为什么每次运行,线程A总是优先于线程C获取锁

分析:

在Hotspot源码中,我们知道synchronized关键字是通过monitor_enter和monitor_exit字节来实现的,最终用于阻塞线程的对象为ObjectMonitor对象,该对象包含三个关键字段:*WaitSet、*cxq、*EntryList。*WaitSet用于保存使用wait方法释放获得的synchronized锁对象的线程,也即我们调用wait函数,那么当前线程将会释放锁,并将自身放入等待集中。而cxq队列用于存放竞争ObjectMonitor锁对象失败的线程,而_EntryList用于也用于存放竞争锁失败的线程。那么它们之间有何区别呢?这是由于我们需要频繁的释放和获取锁,当我们获取锁失败那么将需要把线程放入竞争列表中,当唤醒时需要从竞争列表中获取线程唤醒获取锁,而如果我们只用一个列表来完成这件事,那么将会导致锁争用导致CPU资源浪费且影响性能,这时我们独立出两个列表,其中cxq列表用于竞争放入线程,而entrylist用于单线程唤醒操作。具体策略是这样的:

线程竞争锁失败后CAS放入cxq列表中

线程释放锁后将根据策略来唤醒cxq或者entrylist中的线程(我们这里只讨论默认策略)

默认策略下优先唤醒entrylist列表中的线程,因为唤醒线程对象的操作是单线程的,也即只有获取锁并且释放锁的线程可以操作,所以操作entrylist是线程安全的

如果entrylist列表为空,那么将会CAS将cxq中的等待线程一次性获取到entrylist中并开始逐个唤醒

在hotspot中我们称这种算法为电梯算法,也即将需要唤醒的线程一次性从竞争队列中放入entrylist唤醒队列。

那么这时我们就可以分析以上代码为何总是唤醒线程A了,我们先看线程执行顺序,首先启动线程A,随后线程A启动线程B,B线程需要获取对象锁从而创建线程C,我们看到当线程A调用wait方法将自己放入等待集中后,将会唤醒线程B,随后线程B创建并启动了线程C,然后等待C开始执行,由于此时对象锁由线程B持有,所以线程C需要放入cxq竞争队列,随后B从睡眠中醒来,执行notify方法,该方法总是唤醒了线程A而不是C,也即优先处理等待集中的线程而不是cxq竞争队列的线程。那么我们通过notify方法来看看实现原理。Notify便是Wait操作的反向操作,所以这里很简单,无非就是将线程从等待集中移出并且唤醒。源码如下。

JVM_ENTRY(void,JVM_MonitorNotify(JNIEnv*env,jobjecthandle))Handleobj(THREAD,JNIHandles::resolve_non_null(handle));//直接调用ObjectSynchronizer::notifyObjectSynchronizer::notify(obj,CHECK);JVM_END

这里直接跟进ObjectSynchronizer::notify。源码如下。

voidObjectSynchronizer::notify(Handleobj,TRAPS){if(UseBiasedLocking){//如果使用偏向锁,那么取消偏向锁BiasedLocking::revoke_and_rebias(obj,false,THREAD);}markOopmark=obj-mark();if(mark-has_locker()THREAD-is_lock_owned((address)mark-locker())){//如果是轻量级锁,那么直接返回,因为wait操作需要通过对象监视器来做return;}ObjectSynchronizer::inflate(THREAD,obj())-notify(THREAD);}

可以看到最终调用了ObjectSynchronizer的notify方法来唤醒。源码如下。

voidObjectMonitor::notify(TRAPS){CHECK_OWNER();if(_WaitSet==NULL){//如果等待集为空,直接返回return;}intPolicy=Knob_MoveNotifyee;//移动策略,这里默认是2Thread::SpinAcquire(_WaitSetLock,"WaitSet-notify");//首先对等待集上自旋锁//调用DequeueWaiter将一个等待线程从等待集中拿出来ObjectWaiter*iterator=DequeueWaiter();if(iterator!=NULL){if(Policy!=4){//如果策略不等于4那么将线程的状态修改为TS_ENTERiterator-TState=ObjectWaiter::TS_ENTER;}iterator-_notified=1;//唤醒计数器Thread*Self=THREAD;iterator-_notifier_tid=Self-osthread()-thread_id();ObjectWaiter*List=_EntryList;if(Policy==0){//如果策略为0,那么头插入到entrylist中if(List==NULL){//如果entrylist为空,那么将当前监视器直接作为_EntryList头结点iterator-_next=iterator-_prev=NULL;_EntryList=iterator;}else{//否则头插List-_prev=iterator;iterator-_next=List;iterator-_prev=NULL;_EntryList=iterator;}}elseif(Policy==1){//如果策略为1,那么插入entrylist的尾部if(List==NULL){iterator-_next=iterator-_prev=NULL;_EntryList=iterator;}else{ObjectWaiter*Tail;for(Tail=List;Tail-_next!=NULL;Tail=Tail-_next);Tail-_next=iterator;iterator-_prev=Tail;iterator-_next=NULL;}}elseif(Policy==2){//如果策略为2,那么如果entrylist为空,那么插入entrylist,否则插入cxq队列if(List==NULL){iterator-_next=iterator-_prev=NULL;_EntryList=iterator;}else{iterator-TState=ObjectWaiter::TS_CXQ;for(;;){ObjectWaiter*Front=_cxq;iterator-_next=Front;if(Atomic::cmpxchg_ptr(iterator,_cxq,Front)==Front){break;}}}}elseif(Policy==3){//如果策略为3,那么直接插入cxqiterator-TState=ObjectWaiter::TS_CXQ;for(;;){ObjectWaiter*Tail;Tail=_cxq;if(Tail==NULL){iterator-_next=NULL;if(Atomic::cmpxchg_ptr(iterator,_cxq,NULL)==NULL){break;}}else{while(Tail-_next!=NULL)Tail=Tail-_next;Tail-_next=iterator;iterator-_prev=Tail;iterator-_next=NULL;break;}}}else{//否则直接唤醒线程,让线程自己去调用enterI进入监视器ParkEvent*ev=iterator-_event;iterator-TState=ObjectWaiter::TS_RUN;OrderAccess::fence();ev-unpark();}}Thread::SpinRelease(_WaitSetLock);//释放等待集自旋锁}

这里有一个方法DequeueWaiter()将线程从等待集中取出来,这里的notify读者都知唤醒一个,很多人都说随机唤醒一个,那么我们这里来看看唤醒算法是什么。源码如下。

inlineObjectWaiter*ObjectMonitor::DequeueWaiter(){ObjectWaiter*waiter=_WaitSet;//很简单对吧,直接从头部拿if(waiter){//如果waiter不为空,那么从等待集中断链DequeueSpecificWaiter(waiter);}returnwaiter;}inlinevoidObjectMonitor::DequeueSpecificWaiter(ObjectWaiter*node){ObjectWaiter*next=node-_next;if(next==node){//如果只有一个节点,那么直接将等待集清空即可_WaitSet=NULL;}else{//否则双向链表的断链基础操作ObjectWaiter*prev=node-_prev;next-_prev=prev;prev-_next=next;if(_WaitSet==node){_WaitSet=next;}}//断开连接后,也需要把断下来的节点,next和prev指针清空node-_next=NULL;node-_prev=NULL;}

那么读者应该可以明显的看到,底层对于唤醒操作是从等待集的头部选择线程唤醒。

总结

通过源码我们看到,为何总是唤醒线程A,这是用于当线程C竞争不到锁时,被放入了cxq队列,而此时entrylist为null,线程A在等待集waitset中,当我们调用notify方法时,由于移动策略默认是2,这时会从等待集的头部将线程A取下,放入到entrylist中,当notify执行完毕后,在执行后面的monitor_exit字节码时将会优先从entrylist中唤醒线程,这就导致了A线程总是被优先执行。

线程执行完isAlive方法返回true问题(谷歌)样例代码:
publicclassThreadAliveTest{publicstaticvoidmain(String[]args)throwsInterruptedException{Threadt1=newThread(()-{("t1start");try{(2000);}catch(InterruptedExceptione){();}("t1");});();Threadt2=newThread(()-{synchronized(t1){("t2start");try{(5000);}catch(InterruptedExceptione){();}("t1isAlive:"+());}});();}}

输出结果:t1startt2startt1t1isAlive:true

问题:

为什么线程结束了,isAlive方法还返回true

分析:

我们首先看看执行流程,线程T1启动后将会睡眠2秒,随后2秒后执行结束,随后线程T2启动,T2首先获取到T1的对象锁,然后睡眠5秒,随后调用T1的isAlive方法判定线程是否存活,那么为什么会输出true呢?我们还得先看看isAlive方法如何实现的。我们来看源码。

publicfinalnativebooleanisAlive();

首先看到isAlive方法由JNI方法实现。我们来看Hotspot源码。

JVM_ENTRY(jboolean,JVM_IsThreadAlive(JNIEnv*env,jobjectjthread))JVMWrapper("JVM_IsThreadAlive");oopthread_oop=JNIHandles::resolve_non_null(jthread);returnjava_lang_Thread::is_alive(thread_oop);JVM_END

我们看到首先通过resolve_non_null方法将jthread转为oop对象thread_oop,随后调用java_lang_Thread的is_alive方法来判断是否存活,我们继续跟进。

booljava_lang_Thread::is_alive(oopjava_thread){JavaThread*thr=java_lang_Thread::thread(java_thread);return(thr!=NULL);}JavaThread*java_lang_Thread::thread(oopjava_thread){return(JavaThread*)java_thread-address_field(_eetop_offset);}

我们看到最后是通过获取javathread对象,也即java的Thread类中的eetop属性,如果该属性为null,那么表明线程已经销毁,也即返回false,如果eetop还在那么返回true,表明线程存活。那么什么是eetop呢?我们还得从线程创建方法入手。

JVM_ENTRY(void,JVM_StartThread(JNIEnv*env,jobjectjthread))JVMWrapper("JVM_StartThread");JavaThread*native_thread=NULL;boolthrow_illegal_thread_state=false;//非法线程状态标识{//Threads_lock上锁,保证C++的线程对象和操作系统原生线程不会被清除。当前方法执行完,也就是栈帧释放时,会释放这里的锁,当然肯定会调用析构函数,而这个对象的析构函数中调用unlock方法释放锁MutexLockermu(Threads_lock);if(java_lang_Thread::thread(JNIHandles::resolve_non_null(jthread))!=NULL){//如果线程不为空,则表明线程已经启动,则为非法状态throw_illegal_thread_state=true;}else{//本来这里可以检测一下stillborn标记来看看线程是否已经停止,但是由于历史原因,就让线程自己玩了,这里就不玩了//取得线程对象的stackSize的大小jlongsize=java_lang_Thread::stackSize(JNIHandles::resolve_non_null(jthread));//开始创建C++Thread对象和原生线程对象,使用无符号的线程栈大小,所以这里不会出现负数size_tsz=size0?(size_t)size:0;//创建JavaThread,这里的thread_entry为传入的运行地址,也就是启动线程,需要一个入口执行点,这个函数地址便是入口执行点native_thread=newJavaThread(thread_entry,sz);//如果osthread不为空,则标记当前线程还没有被使用if(native_thread-osthread()!=NULL){native_thread-prepare(jthread);}}}//如果throw_illegal_thread_state不为0,那么直接抛出异常if(throw_illegal_thread_state){THROW(vmSymbols::java_lang_IllegalThreadStateException());}//原生线程必然不能为空,因为线程是由操作系统创建的,所以没有OS线程,空有个JavaThread类有啥用0.0if(native_thread-osthread()==NULL){deletenative_thread;//直接用C++的delete释放内存THROW_MSG(vmSymbols::java_lang_OutOfMemoryError(),"unabletocreatenewnativethread");}Thread::start(native_thread);//一切准备妥当,开始启动线程JVM_END
voidJavaThread::prepare(jobjectjni_thread,ThreadPriorityprio){//包装当前Java线程对象Handlethread_oop(Thread::current(),JNIHandles::resolve_non_null(jni_thread));//将Java层面的线程Oop对象与JavaThreadC++层面的对象关联set_threadObj(thread_oop());java_lang_Thread::set_thread(thread_oop(),this);//设置优先级if(prio==NoPriority){prio=java_lang_Thread::priority(thread_oop());}Thread::set_priority(this,prio);//将JavaThread类放入到全局线程列表中Threads::add(this);}

我们注意看java_lang_Thread::set_thread方法。我们跟进它的源码。

voidjava_lang_Thread::set_thread(oopjava_thread,JavaThread*thread){//将JavaThreadC++层面的线程对象设置为Java层面的Threadoop对象的eetop变量java_thread-address_field_put(_eetop_offset,(address)thread);}

这下我们知道了eetop变量即使JavaThread对象的地址信息。在了解完eetop如何被设置之后我们得继续看,eetop什么时候被取消。当Java线程执行完Runnable接口的run方法最后一个字节码后,将会调用exit方法。该方法完成线程对象的退出和清理操作,我们重点看ensure_join方法。

voidJavaThread::exit(booldestroy_vm,ExitTypeexit_type){ensure_join(this);}

我们继续跟进ensure_join的源码实现。

staticvoidensure_join(JavaThread*thread){//封装JavaThread线程oop对象HandlethreadObj(thread,thread-threadObj());//获取JavaThread线程oop对象锁ObjectLockerlock(threadObj,thread);//清除未处理的异常信息thread-clear_ping_exception();//将状态修改为TERMINATEDjava_lang_Thread::set_thread_status(threadObj(),java_lang_Thread::TERMINATED);//将JavaThread线程oop对象与JavaThreadC++对象解绑java_lang_Thread::set_thread(threadObj(),NULL);//唤醒所有阻塞在线程对象的线程_all(thread);//如果以上代码期间发生异常,那么清理挂起的异常thread-clear_ping_exception();}

我们看到最终由ensure_join方法中的java_lang_Thread::set_thread(threadObj(),NULL),将eetop变量设置为null,当执行完这一步时,我们再通过isAlive方法判断线程是否存活时,将返回false,否则返回true。而我们看到在操作该变量时需要获取线程对象锁。我们来看ObjectLocker的构造函数和析构函数的实现。

ObjectLocker::ObjectLocker(Handleobj,Thread*thread,booldoLock){_dolock=doLock;_thread=thread;if(_dolock){//获取JavaThread线程oop对象锁ObjectSynchronizer::fast_enter(_obj,_lock,false,_thread);}}ObjectLocker::~ObjectLocker(){if(_dolock){//释放JavaThread线程oop对象锁ObjectSynchronizer::fast_exit(_obj(),_lock,_thread);}}

我们看到当我们创建ObjectLocker对象时,会在构造函数中获取到线程对象锁,而当ensure_join方法执行完毕后,将会调用ObjectLocker的析构函数,在该函数中释放线程对象锁。

总结:

这下我们就可以通过以上知识来分析为何isAlive方法在线程执行完毕后仍然返回true了,这是用于isAlive方法通过判断Java线程对象的eetop变量来判定线程是否存活,而当我们线程执行完毕后将会调用exit方法,该方法将会调用ensure_join方法,在该方法中将eetop甚至为null,但是由于赋值前需要获取到Java线程的对象锁,而该对象的对象锁已经由线程T2持有,这时当前线程将会阻塞,从而造成eetop变量没有被清除,从而导致isAlive方法在T1线程执行完毕后仍然返回true。读者也可以看看javaThread的源码,join函数也是通过对Thread对象获取锁然后调用isAlive来判定线程是否结束的,这就意味着如果我们用别的线程持有了JavaThread的对象锁,那么这时调用join方法的线程也是会被阻塞的。