堆栈

1.原理 函数调用 CALL 指令可拆分为两步操作： 1)、 将调用者的下一条指令（ EIP ）的地址压栈 2)、 跳转至将要调用的函数地址中（相对偏移或绝对地址） 那么在执行到子函数首地址位置时，返回地址（即调用函数中调用位置下一条指令的地址）就已经存在于堆栈中了，并且是 ESP 指向地址的值。下面通过栈帧的概念，了解编译器在接下来对堆栈进行的操作。 简言之，栈帧就是利用 EBP （栈帧指针，请注意不是 ESP ）寄存器访问栈内部局部变量、参数、函数返回地址等的手段。程序运行中， ESP 寄存器的值随时变化，访问栈中函数的局部变量、参数时，若以 ESP 值为基准编写程序会十分困难，并且也很难使 CPU 引用到正确的地址。 所以，调用某函数时，先要把用作基准点（函数起始地址）的 ESP 值保存到 EBP ，并维持在函数内部。这样，无论 ESP 的值如何变化，以 EBP 的值为基准能够安全访问到相关函数的局部变量、参数、返回地址，这就是 EBP 寄存器作为栈帧指针的作用。 在函数体代码的任何位置，EBP 寄存器指向的地址始终存储属于它的调用函数的 EBP 的值，根据这个原理可逐级向调用函数、调用函数的调用函数进行遍历，向上回溯。 这样有什么用呢？ 在将属于调用函数的 EBP 的值压栈之前， ESP 指向的地址存储的是由 CALL 指令压栈的调用函数中调用位置的下一条指令的地址（原

1.CPU移植要求： 1 ） 处理器有对应的能产生可重入代码的 C 编译器 2 ） 处理器支持中断且能提供周期性的中断（通常介于 10 到 1000Hz 之 间）。 3 ） 可以关中断和开中断 4 ） 处理器支持存储和载入堆栈指针、 CPU 寄存器、堆栈的指令。 5 ） 处理器有足够的 RAM 用于存放 uC/OS-III 的变量、 结构体、 内部 任务堆栈、任务堆栈等 6 ） 编译器支持 64 位的数据类型 2. uC/OS-III 的架构和它与其他软件、硬件成分的关系： （ 1 ）移植 uC/OS-III 需修改 3 个与内核相关的文件： OS_CPU.H 、 OS_CPU_A.ASM 、 OS_CPU_C.C 。 （ 2 ）移植 uC/OS-III 需修改 3 个与 CPU 相关的文件： CPU.H 、 CPU_A.ASM 、 CPU_CORE.C 。 （ 3 ） BSP 中通常包含了 uC/OS-III 与定时器（产生时基的定时 器 ）、中断控制器的接口。 （ 4 ） 有些半导体厂商会提高相应的固件库文件， 这些文件会被 包含在 CPU/MCU 中。 移植包括三方面内容： CPU 、 OS 、 BSP 。 2. uC/CPU 与 CPU 相关的代码决定于 CPU 的架构。 例如， 关中断和开中断、 堆栈的字长， 堆栈的生长方向等等。与 CPU 相关的代码被封装在叫 做 uC

众所周知啦，我们数学里面的公式就是中缀表达式(infix)，形如a*(b+c)，支持括号用于调整运算的顺序。我们平常用的就是中缀表达式。 那么什么是后缀表达式(postfix)？ 后缀表达式(又称为逆波兰reverse polish)就是不需要括号就可以实现调整运算顺序的一种技法。 比如：ab+cde+** 上面就是一个典型的后缀表达式，将它改为中缀表达式其实是(a+b)*((d+e)*c)。我们这样将后缀表达式转换成中缀表达式，虽然符合我们的数学计算习惯，但是并不符合计算机运算的方式。我们可以通过数据结构中的栈来理解后缀表达式和它为什么符合计算机计算。 什么是栈(stack)呢？简单的说就是LIFO(后入先出)。画一张图就是下面这样 堆栈的操作其实很简单，你可以把堆栈想象成一个汉诺塔，你可以在塔顶不断加上汉诺圈，可以从顶部一个一个拿走，但是你不能直接从下面拿走最先放的那个圈。所以你懂了吧，要想拿到最先那个，你必须取出所有的圈，而你最后摆上去的圈可以被立刻拿到。这就是LIFO的本质。 堆栈的实现方法可以是链表或者数组。它们各有各得优点，它们的对比网络上有很多啦，当然我以后也会写出来。 现在你知道了栈这种结构就可以重新理解一遍后缀表达式。我们就以 "ab+cde+**" 这个表达式举例。我们创建一个栈，然后从这个表达式开头(当然是从左边)扫描，如果扫描到的是数据就压(push)到栈中

技术博客：https://github.com/yongxinz/tech-blog 同时，也欢迎关注我的微信公众号 AlwaysBeta ，更多精彩内容等你来。 用于创建和使用上下文管理器的实用程序。 contextlib 模块包含用于处理上下文管理器和 with 语句的实用程序。 Context Manager API 上下文管理器负责一个代码块内的资源，从进入块时创建到退出块后清理。例如，文件上下文管理器 API，在完成所有读取或写入后来确保它们已关闭。 with open ( '/tmp/pymotw.txt' , 'wt' ) as f : f . write ( 'contents go here' ) # file is automatically closed with 语句启用了上下文管理器，API 涉及两种方法：当执行流进入内部代码块时运行 __enter__() 方法，它返回要在上下文中使用的对象。当执行流离开 with 块时，调用上下文管理器的 __exit__() 方法来清理正在使用的任何资源。 class Context : def __init__ ( self ) : print ( '__init__()' ) def __enter__ ( self ) : print ( '__enter__()' ) return self def _

姓名：吕松鸿 学号：20135229 （ *原创作品转载请注明出处*） （ 学习课程：《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000 ） 一、存储程序计算机 1.1冯诺依曼体系结构：即具有存储程序的计算机体系结构 目前大多数拥有计算和存储功能的设备（智能手机、平板、计算机等）其核心构造均为冯诺依曼体系结构 从硬件来看 CPU与内存通过主线连接，CPU上的IP（可能是16、32、64位）总指向内存的某一块区域；IP指向的CS（代码段）也在内存中；CPU总是执行IP指向的指令。 2. 从软件来看 API（应用程序编程接口，与编程人员）与ABI（程序与CPU的借口界面） 是两个比较重要的软件接口 1.2 关于ABI：指令编码；指令中涉及的寄存器布局；大多数指令可以直接访问内存 1.3 （E代表32位系统）EIP在CPU执行完一条指令之后自加一（自动加一条指令，而不是一个字节或是32位），当然也可以被其它指令，如CALL,RET等修改 二、x86汇编基础 2.1 x86（32位）的寄存器中，低16位作为16位register 2.2 关于堆栈段寄存器 EBP（堆栈基址寄存器）；ESP（堆栈顶指针寄存器）。上述两个寄存器较为频繁地使用于汇编程序中 2.3 关于代码段寄存器 CPU实际取指令的时候通过cs

32位CPU所含有的寄存器有： PQJI~u9te} 4个数据寄存器(EAX、EBX、ECX和EDX) <,\Op=$l3I 2个变址和指针寄存器(ESI和EDI) 2个指针寄存器(ESP和EBP) ']'V?@H]4 6个段寄存器(ES、CS、SS、DS、FS和GS) ZaKT~f%%z 1个指令指针寄存器(EIP) 1个标志寄存器(EFlags) f*HEw 1、数据寄存器 s ~ Xa= +D 数据寄存器主要用来保存操作数和运算结果等信息，从而节省读取操作数所需占用总线和访问存储器的时间。 3Gyw^ {J 32位CPU有4个32位的通用寄存器EAX、EBX、ECX和EDX。 {!]7=K)W9 对低16位数据的存取，不会影响高16位的数据。 COnb@uD 这些低16位寄存器分别命名为：AX、BX、CX和DX，它和先前的CPU中的寄存器相一致。 90rY:!e 4个16位寄存器又可分割成8个独立的8位寄存器(AX：AH-AL、BX：BH-BL、CX：CH-CL、DX：DH-DL)，每个寄存器都有自己的名称，可独立存取。 ~bsL W:.’ 程序员可利用数据寄存器的这种“可分可合”的特性，灵活地处理字/字节的信息。 %‘L+y 寄存器EAX通常称为累加器(Accumulator)，用累加器进行的操作可能需要更少时间。可用于乘、 除、输入/输出等操作，使用频率很高； E

前言 场景：C++通过JNI将数据传输给Java程序 问题：运行一段时间String对象和Char字符不停变大，直到内存溢出（JVM-OOM） 1 过程 Jmap初步分析头部对象内存占用 PS：jmap -histo:live <pid>，执行该方法会同步执行一次GC，所以，展示的都是无法GC的对象。 发现：String对象有28万个，可能存在String对象被长期持有的现象，初步怀疑是HashMap等缓存持有 Jmap导出堆栈分析：导出堆栈时String对象是21万个 jmap -dump:live,format=b,file=/root/edr.bin 17994 用eclipse-mat打开堆栈文件：通过Histogram看看对象实例数 发现：String对象确实是21万个 看看String对象来自于哪里，并将String列表按RetainedHeap倒叙排列 发现：String对象是来自于本地JNI线程，且这个JNI线程还持有大量的内存 查看程序线程内存占用情况 发现：存在10个相似的线程，都占用了很多内存，且线程类型还是守护类型，但是无法通过线程名判断是什么线程对象 查看线程持有哪些对象 发现：线程持有14759个String对象，基本可以判断是该类（10个）线程没有将JNI-String内存释放 最终确认确实是C++JNI相关代码没有释放内存 2 总结

进程上下文，意思是可执行程序代码是进程的重要组成部分。进程上下文实际上是进程执行活动全过程的静态描述。 这些代码从 可执行文件 载入到进程的 地址空间 执行。一般程序在 用户空间 执行当一个程序调用了 系统调用 或者触发了某个异常，它就陷入了 内核空间 。此时，我们称 内核 “代表进程执行”并处于进程上下文。在此上下文中current宏是有效的。除非在此间隙有更高 优先级 的进程需要执行并由调度器做出了相应调整，否则在内核退出的时候，程序恢复在用户空间继续执行。 系统调用和 异常处理 程序是对内核明确定义的接口。进程只有通过这些接口才能陷入内核执行——对内核的所有访问都必须通过这些接口。 进程上下文实际上是进程执行活动全过程的静态描述。我们把已执行过的进程指令和数据在相关 寄存器 与 堆栈 中的内容称为上文，把正在执行的指令和数据在寄存器和堆栈中的内容称为正文，把待执行的指令和数据在寄存器与堆栈中的内容称为下文。具体的说，进程上下文包括计算机系统中与执行该进程有关的各种寄存器（例如 通用寄存器 ， 程序计数器 PC ， 程序状态字寄存器 PS等）的值， 程序段 在经过编译过后形成的 机器指令 代码集，数据集及各种堆栈值PCB结构。这里，有关寄存器和栈区的内容是重要的，例如没有程序计数器PC和程序　 状态寄存器 PS，CPU将无法知道下一条待执行指令的地址和控制有关操作。

CAS算法实现一个重要前提需要取出内存中某时刻的数据，而在下时刻比较并替换，那么在这个时间差类会导致数据的变化。 比如说一个线程one从内存位置V中取出A，这时候另一个线程two也从内存中取出A，并且two进行了一些操作变成了B，然后two又将V位置的数据变成A，这时候线程one进行CAS操作发现内存中仍然是A，然后one操作成功。尽管线程one的CAS操作成功，但是不代表这个过程就是没有问题的。如果链表的头在变化了两次后恢复了原值，但是不代表链表就没有变化。因此前面提到的原子操作AtomicStampedReference/AtomicMarkableReference就很有用了。这允许一对变化的元素进行原子操作。 在运用CAS做Lock-Free操作中有一个经典的ABA问题： 线程1准备用CAS将变量的值由A替换为B，在此之前，线程2将变量的值由A替换为C，又由C替换为A，然后线程1执行CAS时发现变量的值仍然为A，所以CAS成功。但实际上这时的现场已经和最初不同了，尽管CAS成功，但可能存在潜藏的问题，例如下面的例子： 现有一个用单向链表实现的堆栈，栈顶为A，这时线程T1已经知道A.next为B，然后希望用CAS将栈顶替换为B： head.compareAndSet(A,B); 在T1执行上面这条指令之前，线程T2介入，将A、B出栈，再pushD、C、A，此时堆栈结构如下图

中缀表达式 即算术表达式。如，a+b*c-d/e 后缀表达式 运算符号位于两个运算数之后。如， a b c * + d e /- 前缀表达式 前缀表达式的运算符位于两个相应操作数之前。如，-+*abc/de 用栈实现：特指运算符的入出栈的操作 每次运算符出栈都代表的是一个结果 例题： 1.令P代表入栈，O代表出栈。若利用堆栈将中缀表达式3*2+8/4转为后缀表达式，则相应的堆栈操作序列是： 解: *入栈，然后出栈 +入栈，/入栈，然后分别出栈 PPPOOO 来源： CSDN 作者： Mia@ 链接： https://blog.csdn.net/weixin_43008312/article/details/103788825