首页 文章 精选 留言 我的

精选列表

搜索[基础搭建],共10000篇文章
优秀的个人博客,低调大师

每日一博 | 进程和线程基础知识全家桶,30 张图一套带走

前言 先来看看一则小故事 我们写好的一行行代码,为了让其工作起来,我们还得把它送进城(进程)里,那既然进了城里,那肯定不能胡作非为了。 城里人有城里人的规矩,城中有个专门管辖你们的城管(操作系统),人家让你休息就休息,让你工作就工作,毕竟摊位(CPU)就一个,每个人都要占这个摊位来工作,城里要工作的人多着去了。 所以城管为了公平起见,它使用一种策略(调度)方式,给每个人一个固定的工作时间(时间片),时间到了就会通知你去休息而换另外一个人上场工作。 另外,在休息时候你也不能偷懒,要记住工作到哪了,不然下次到你工作了,你忘记工作到哪了,那还怎么继续? 有的人,可能还进入了县城(线程)工作,这里相对轻松一些,在休息的时候,要记住的东西相对较少,而且还能共享城里的资源。 “哎哟,难道本文内容是进程和线程?” 可以,聪明的你猜出来了,也不枉费我瞎编乱造的故事了。 进程和线程对于写代码的我们,真的天天见、日日见了,但见的多不代表你就熟悉它们,比如简单问你一句,你知道它们的工作原理和区别吗? 不知道没关系,今天就要跟大家讨论操作系统的进程和线程。 提纲 正文 进程 我们编写的代码只是一个存储在硬盘的静态文件,通过编译后就会生成二进制可执行文件,当我们运行这个可执行文件后,它会被装载到内存中,接着 CPU 会执行程序中的每一条指令,那么这个运行中的程序,就被称为「进程」。 现在我们考虑有一个会读取硬盘文件数据的程序被执行了,那么当运行到读取文件的指令时,就会去从硬盘读取数据,但是硬盘的读写速度是非常慢的,那么在这个时候,如果 CPU 傻傻的等硬盘返回数据的话,那 CPU 的利用率是非常低的。 做个类比,你去煮开水时,你会傻傻的等水壶烧开吗?很明显,小孩也不会傻等。我们可以在水壶烧开之前去做其他事情。当水壶烧开了,我们自然就会听到“嘀嘀嘀”的声音,于是再把烧开的水倒入到水杯里就好了。 所以,当进程要从硬盘读取数据时,CPU 不需要阻塞等待数据的返回,而是去执行另外的进程。当硬盘数据返回时,CPU 会收到个中断,于是 CPU 再继续运行这个进程。 进程 1 与进程 2 切换 这种多个程序、交替执行的思想,就有 CPU 管理多个进程的初步想法。 对于一个支持多进程的系统,CPU 会从一个进程快速切换至另一个进程,其间每个进程各运行几十或几百个毫秒。 虽然单核的 CPU 在某一个瞬间,只能运行一个进程。但在 1 秒钟期间,它可能会运行多个进程,这样就产生并行的错觉,实际上这是并发。 并发和并行有什么区别? 一图胜千言。 并发与并行 进程与程序的关系的类比 到了晚饭时间,一对小情侣肚子都咕咕叫了,于是男生见机行事,就想给女生做晚饭,所以他就在网上找了辣子鸡的菜谱,接着买了一些鸡肉、辣椒、香料等材料,然后边看边学边做这道菜。 突然,女生说她想喝可乐,那么男生只好把做菜的事情暂停一下,并在手机菜谱标记做到哪一个步骤,把状态信息记录了下来。 然后男生听从女生的指令,跑去下楼买了一瓶冰可乐后,又回到厨房继续做菜。 这体现了,CPU 可以从一个进程(做菜)切换到另外一个进程(买可乐),在切换前必须要记录当前进程中运行的状态信息,以备下次切换回来的时候可以恢复执行。 所以,可以发现进程有着「运行 - 暂停 - 运行」的活动规律。 进程的状态 在上面,我们知道了进程有着「运行 - 暂停 - 运行」的活动规律。一般说来,一个进程并不是自始至终连续不停地运行的,它与并发执行中的其他进程的执行是相互制约的。 它有时处于运行状态,有时又由于某种原因而暂停运行处于等待状态,当使它暂停的原因消失后,它又进入准备运行状态。 所以,在一个进程的活动期间至少具备三种基本状态,即运行状态、就绪状态、阻塞状态。 进程的三种基本状态 上图中各个状态的意义: 运行状态(Runing):该时刻进程占用 CPU; 就绪状态(Ready):可运行,但因为其他进程正在运行而暂停停止; 阻塞状态(Blocked):该进程正在等待某一事件发生(如等待输入/输出操作的完成)而暂时停止运行,这时,即使给它CPU控制权,它也无法运行; 当然,进程另外两个基本状态: 创建状态(new):进程正在被创建时的状态; 结束状态(Exit):进程正在从系统中消失时的状态; 于是,一个完整的进程状态的变迁如下图: 进程五种状态的变迁 再来详细说明一下进程的状态变迁: NULL -> 创建状态:一个新进程被创建时的第一个状态; 创建状态 -> 就绪状态:当进程被创建完成并初始化后,一切就绪准备运行时,变为就绪状态,这个过程是很快的; 就绪态 -> 运行状态:处于就绪状态的进程被操作系统的进程调度器选中后,就分配给 CPU 正式运行该进程; 运行状态 -> 结束状态:当进程已经运行完成或出错时,会被操作系统作结束状态处理; 运行状态 -> 就绪状态:处于运行状态的进程在运行过程中,由于分配给它的运行时间片用完,操作系统会把该进程变为就绪态,接着从就绪态选中另外一个进程运行; 运行状态 -> 阻塞状态:当进程请求某个事件且必须等待时,例如请求 I/O 事件; 阻塞状态 -> 就绪状态:当进程要等待的事件完成时,它从阻塞状态变到就绪状态; 另外,还有一个状态叫挂起状态,它表示进程没有占有内存空间。这跟阻塞状态是不一样,阻塞状态是等待某个事件的返回。 由于虚拟内存管理原因,进程的所使用的空间可能并没有映射到物理内存,而是在硬盘上,这时进程就会出现挂起状态。 虚拟内存管理-换入换出 挂起状态可以分为两种: 阻塞挂起状态:进程在外存(硬盘)并等待某个事件的出现; 就绪挂起状态:进程在外存(硬盘),但只要进入内存,即刻立刻运行; 这两种挂起状态加上前面的五种状态,就变成了七种状态变迁(留给我的颜色不多了),见如下图: 七种状态变迁 进程的控制结构 在操作系统中,是用进程控制块(process control block,PCB)数据结构来描述进程的。 那 PCB 是什么呢?打开知乎搜索你就会发现这个东西并不是那么简单。 知乎搜 PCB 的提示 打住打住,我们是个正经的人,怎么会去看那些问题呢?是吧,回来回来。 PCB 是进程存在的唯一标识,这意味着一个进程的存在,必然会有一个 PCB,如果进程消失了,那么 PCB 也会随之消失。 PCB 具体包含什么信息呢? 进程描述信息: 进程标识符:标识各个进程,每个进程都有一个并且唯一的标识符; 用户标识符:进程归属的用户,用户标识符主要为共享和保护服务; 进程控制和管理信息: 进程当前状态,如 new、ready、running、waiting 或 blocked 等; 进程优先级:进程抢占 CPU 时的优先级; 资源分配清单: 有关内存地址空间或虚拟地址空间的信息,所打开文件的列表和所使用的 I/O 设备信息。 CPU 相关信息: CPU 中各个寄存器的值,当进程被切换时,CPU 的状态信息都会被保存在相应的 PCB 中,以便进程重新执行时,能从断点处继续执行。 可见,PCB 包含信息还是比较多的。 每个 PCB 是如何组织的呢? 通常是通过链表的方式进行组织,把具有相同状态的进程链在一起,组成各种队列。比如: 将所有处于就绪状态的进程链在一起,称为就绪队列; 把所有因等待某事件而处于等待状态的进程链在一起就组成各种阻塞队列; 另外,对于运行队列在单核 CPU 系统中则只有一个运行指针了,因为单核 CPU 在某个时间,只能运行一个程序。 那么,就绪队列和阻塞队列链表的组织形式如下图: 就绪队列和阻塞队列 除了链接的组织方式,还有索引方式,它的工作原理:将同一状态的进程组织在一个索引表中,索引表项指向相应的 PCB,不同状态对应不同的索引表。 一般会选择链表,因为可能面临进程创建,销毁等调度导致进程状态发生变化,所以链表能够更加灵活的插入和删除。 进程的控制 我们熟知了进程的状态变迁和进程的数据结构 PCB 后,再来看看进程的创建、终止、阻塞、唤醒的过程,这些过程也就是进程的控制。 01 创建进程 操作系统允许一个进程创建另一个进程,而且允许子进程继承父进程所拥有的资源,当子进程被终止时,其在父进程处继承的资源应当还给父进程。同时,终止父进程时同时也会终止其所有的子进程。 创建进程的过程如下: 为新进程分配一个唯一的进程标识号,并申请一个空白的 PCB,PCB 是有限的,若申请失败则创建失败; 为进程分配资源,此处如果资源不足,进程就会进入等待状态,以等待资源; 初始化 PCB; 如果进程的调度队列能够接纳新进程,那就将进程插入到就绪队列,等待被调度运行; 02 终止进程 进程可以有 3 种终止方式:正常结束、异常结束以及外界干预(信号 kill 掉)。 终止进程的过程如下: 查找需要终止的进程的 PCB; 如果处于执行状态,则立即终止该进程的执行,然后将 CPU 资源分配给其他进程; 如果其还有子进程,则应将其所有子进程终止; 将该进程所拥有的全部资源都归还给父进程或操作系统; 将其从 PCB 所在队列中删除; 03 阻塞进程 当进程需要等待某一事件完成时,它可以调用阻塞语句把自己阻塞等待。而一旦被阻塞等待,它只能由另一个进程唤醒。 阻塞进程的过程如下: 找到将要被阻塞进程标识号对应的 PCB; 如果该进程为运行状态,则保护其现场,将其状态转为阻塞状态,停止运行; 将该 PCB 插入的阻塞队列中去; 04 唤醒进程 进程由「运行」转变为「阻塞」状态是由于进程必须等待某一事件的完成,所以处于阻塞状态的进程是绝对不可能叫醒自己的。 如果某进程正在等待 I/O 事件,需由别的进程发消息给它,则只有当该进程所期待的事件出现时,才由发现者进程用唤醒语句叫醒它。 唤醒进程的过程如下: 在该事件的阻塞队列中找到相应进程的 PCB; 将其从阻塞队列中移出,并置其状态为就绪状态; 把该 PCB 插入到就绪队列中,等待调度程序调度; 进程的阻塞和唤醒是一对功能相反的语句,如果某个进程调用了阻塞语句,则必有一个与之对应的唤醒语句。 进程的上下文切换 各个进程之间是共享 CPU 资源的,在不同的时候进程之间需要切换,让不同的进程可以在 CPU 执行,那么这个一个进程切换到另一个进程运行,称为进程的上下文切换。 在详细说进程上下文切换前,我们先来看看 CPU 上下文切换 大多数操作系统都是多任务,通常支持大于 CPU 数量的任务同时运行。实际上,这些任务并不是同时运行的,只是因为系统在很短的时间内,让各个任务分别在 CPU 运行,于是就造成同时运行的错误。 任务是交给 CPU 运行的,那么在每个任务运行前,CPU 需要知道任务从哪里加载,又从哪里开始运行。 所以,操作系统需要事先帮 CPU 设置好 CPU 寄存器和程序计数器。 CPU 寄存器是 CPU 内部一个容量小,但是速度极快的内存(缓存)。我举个例子,寄存器像是你的口袋,内存像你的书包,硬盘则是你家里的柜子,如果你的东西存放到口袋,那肯定是比你从书包或家里柜子取出来要快的多。 再来,程序计数器则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。 所以说,CPU 寄存器和程序计数是 CPU 在运行任何任务前,所必须依赖的环境,这些环境就叫做 CPU 上下文。 既然知道了什么是 CPU 上下文,那理解 CPU 上下文切换就不难了。 CPU 上下文切换就是先把前一个任务的 CPU 上下文(CPU 寄存器和程序计数器)保存起来,然后加载新任务的上下文到这些寄存器和程序计数器,最后再跳转到程序计数器所指的新位置,运行新任务。 系统内核会存储保持下来的上下文信息,当此任务再次被分配给 CPU 运行时,CPU 会重新加载这些上下文,这样就能保证任务原来的状态不受影响,让任务看起来还是连续运行。 上面说到所谓的「任务」,主要包含进程、线程和中断。所以,可以根据任务的不同,把 CPU 上下文切换分成:进程上下文切换、线程上下文切换和中断上下文切换。 进程的上下文切换到底是切换什么呢? 进程是由内核管理和调度的,所以进程的切换只能发生在内核态。 所以,进程的上下文切换不仅包含了虚拟内存、栈、全局变量等用户空间的资源,还包括了内核堆栈、寄存器等内核空间的资源。 通常,会把交换的信息保存在进程的 PCB,当要运行另外一个进程的时候,我们需要从这个进程的 PCB 取出上下文,然后恢复到 CPU 中,这使得这个进程可以继续执行,如下图所示: 进程上下文切换 大家需要注意,进程的上下文开销是很关键的,我们希望它的开销越小越好,这样可以使得进程可以把更多时间花费在执行程序上,而不是耗费在上下文切换。 发生进程上下文切换有哪些场景? 为了保证所有进程可以得到公平调度,CPU 时间被划分为一段段的时间片,这些时间片再被轮流分配给各个进程。这样,当某个进程的时间片耗尽了,就会被系统挂起,切换到其它正在等待 CPU 的进程运行; 进程在系统资源不足(比如内存不足)时,要等到资源满足后才可以运行,这个时候进程也会被挂起,并由系统调度其他进程运行; 当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时,自然也会重新调度; 当有优先级更高的进程运行时,为了保证高优先级进程的运行,当前进程会被挂起,由高优先级进程来运行; 发生硬件中断时,CPU 上的进程会被中断挂起,转而执行内核中的中断服务程序; 以上,就是发生进程上下文切换的常见场景了。 线程 在早期的操作系统中都是以进程作为独立运行的基本单位,直到后面,计算机科学家们又提出了更小的能独立运行的基本单位,也就是线程。 为什么使用线程? 我们举个例子,假设你要编写一个视频播放器软件,那么该软件功能的核心模块有三个: 从视频文件当中读取数据; 对读取的数据进行解压缩; 把解压缩后的视频数据播放出来; 对于单进程的实现方式,我想大家都会是以下这个方式: 单进程实现方式 对于单进程的这种方式,存在以下问题: 播放出来的画面和声音会不连贯,因为当 CPU 能力不够强的时候,Read 的时候可能进程就等在这了,这样就会导致等半天才进行数据解压和播放; 各个函数之间不是并发执行,影响资源的使用效率; 那改进成多进程的方式: 多进程实现方式 对于多进程的这种方式,依然会存在问题: 进程之间如何通信,共享数据? 维护进程的系统开销较大,如创建进程时,分配资源、建立 PCB;终止进程时,回收资源、撤销 PCB;进程切换时,保存当前进程的状态信息; 那到底如何解决呢?需要有一种新的实体,满足以下特性: 实体之间可以并发运行; 实体之间共享相同的地址空间; 这个新的实体,就是线程( Thread ),线程之间可以并发运行且共享相同的地址空间。 什么是线程? 线程是进程当中的一条执行流程。 同一个进程内多个线程之间可以共享代码段、数据段、打开的文件等资源,但每个线程都有独立一套的寄存器和栈,这样可以确保线程的控制流是相对独立的。 多线程 线程的优缺点? 线程的优点: 一个进程中可以同时存在多个线程; 各个线程之间可以并发执行; 各个线程之间可以共享地址空间和文件等资源; 线程的缺点: 当进程中的一个线程奔溃时,会导致其所属进程的所有线程奔溃。 举个例子,对于游戏的用户设计,则不应该使用多线程的方式,否则一个用户挂了,会影响其他同个进程的线程。 线程与进程的比较 线程与进程的比较如下: 进程是资源(包括内存、打开的文件等)分配的单位,线程是 CPU 调度的单位; 进程拥有一个完整的资源平台,而线程只独享必不可少的资源,如寄存器和栈; 线程同样具有就绪、阻塞、执行三种基本状态,同样具有状态之间的转换关系; 线程能减少并发执行的时间和空间开销; 对于,线程相比进程能减少开销,体现在: 线程的创建时间比进程快,因为进程在创建的过程中,还需要资源管理信息,比如内存管理信息、文件管理信息,而线程在创建的过程中,不会涉及这些资源管理信息,而是共享它们; 线程的终止时间比进程快,因为线程释放的资源相比进程少很多; 同一个进程内的线程切换比进程切换快,因为线程具有相同的地址空间(虚拟内存共享),这意味着同一个进程的线程都具有同一个页表,那么在切换的时候不需要切换页表。而对于进程之间的切换,切换的时候要把页表给切换掉,而页表的切换过程开销是比较大的; 由于同一进程的各线程间共享内存和文件资源,那么在线程之间数据传递的时候,就不需要经过内核了,这就使得线程之间的数据交互效率更高了; 所以,线程比进程不管是时间效率,还是空间效率都要高。 线程的上下文切换 在前面我们知道了,线程与进程最大的区别在于:线程是调度的基本单位,而进程则是资源拥有的基本单位。 所以,所谓操作系统的任务调度,实际上的调度对象是线程,而进程只是给线程提供了虚拟内存、全局变量等资源。 对于线程和进程,我们可以这么理解: 当进程只有一个线程时,可以认为进程就等于线程; 当进程拥有多个线程时,这些线程会共享相同的虚拟内存和全局变量等资源,这些资源在上下文切换时是不需要修改的; 另外,线程也有自己的私有数据,比如栈和寄存器等,这些在上下文切换时也是需要保存的。 线程上下文切换的是什么? 这还得看线程是不是属于同一个进程: 当两个线程不是属于同一个进程,则切换的过程就跟进程上下文切换一样; 当两个线程是属于同一个进程,因为虚拟内存是共享的,所以在切换时,虚拟内存这些资源就保持不动,只需要切换线程的私有数据、寄存器等不共享的数据; 所以,线程的上下文切换相比进程,开销要小很多。 线程的实现 主要有三种线程的实现方式: 用户线程(User Thread):在用户空间实现的线程,不是由内核管理的线程,是由用户态的线程库来完成线程的管理; 内核线程(Kernel Thread):在内核中实现的线程,是由内核管理的线程; 轻量级进程(LightWeight Process):在内核中来支持用户线程; 那么,这还需要考虑一个问题,用户线程和内核线程的对应关系。 首先,第一种关系是多对一的关系,也就是多个用户线程对应同一个内核线程: 多对一 第二种是一对一的关系,也就是一个用户线程对应一个内核线程: 一对一 第三种是多对多的关系,也就是多个用户线程对应到多个内核线程: 多对多 用户线程如何理解?存在什么优势和缺陷? 用户线程是基于用户态的线程管理库来实现的,那么线程控制块(Thread Control Block, TCB) 也是在库里面来实现的,对于操作系统而言是看不到这个 TCB 的,它只能看到整个进程的 PCB。 所以,用户线程的整个线程管理和调度,操作系统是不直接参与的,而是由用户级线程库函数来完成线程的管理,包括线程的创建、终止、同步和调度等。 用户级线程的模型,也就类似前面提到的多对一的关系,即多个用户线程对应同一个内核线程,如下图所示: 用户级线程模型 用户线程的优点: 每个进程都需要有它私有的线程控制块(TCB)列表,用来跟踪记录它各个线程状态信息(PC、栈指针、寄存器),TCB 由用户级线程库函数来维护,可用于不支持线程技术的操作系统; 用户线程的切换也是由线程库函数来完成的,无需用户态与内核态的切换,所以速度特别快; 用户线程的缺点: 由于操作系统不参与线程的调度,如果一个线程发起了系统调用而阻塞,那进程所包含的用户线程都不能执行了。 当一个线程开始运行后,除非它主动地交出 CPU 的使用权,否则它所在的进程当中的其他线程无法运行,因为用户态的线程没法打断当前运行中的线程,它没有这个特权,只有操作系统才有,但是用户线程不是由操作系统管理的。 由于时间片分配给进程,故与其他进程比,在多线程执行时,每个线程得到的时间片较少,执行会比较慢; 以上,就是用户线程的优缺点了。 那内核线程如何理解?存在什么优势和缺陷? 内核线程是由操作系统管理的,线程对应的 TCB 自然是放在操作系统里的,这样线程的创建、终止和管理都是由操作系统负责。 内核线程的模型,也就类似前面提到的一对一的关系,即一个用户线程对应一个内核线程,如下图所示: 内核线程模型 内核线程的优点: 在一个进程当中,如果某个内核线程发起系统调用而被阻塞,并不会影响其他内核线程的运行; 分配给线程,多线程的进程获得更多的 CPU 运行时间; 内核线程的缺点: 在支持内核线程的操作系统中,由内核来维护进程和线程的上下问信息,如 PCB 和 TCB; 线程的创建、终止和切换都是通过系统调用的方式来进行,因此对于系统来说,系统开销比较大; 以上,就是内核线的优缺点了。 最后的轻量级进程如何理解? 轻量级进程(Light-weight process,LWP)是内核支持的用户线程,一个进程可有一个或多个 LWP,每个 LWP 是跟内核线程一对一映射的,也就是 LWP 都是由一个内核线程支持。 另外,LWP 只能由内核管理并像普通进程一样被调度,Linux 内核是支持 LWP 的典型例子。 在大多数系统中,LWP与普通进程的区别也在于它只有一个最小的执行上下文和调度程序所需的统计信息。一般来说,一个进程代表程序的一个实例,而 LWP 代表程序的执行线程,因为一个执行线程不像进程那样需要那么多状态信息,所以 LWP 也不带有这样的信息。 在 LWP 之上也是可以使用用户线程的,那么 LWP 与用户线程的对应关系就有三种: 1 : 1,即一个 LWP 对应 一个用户线程; N : 1,即一个 LWP 对应多个用户线程; N : N,即多个 LMP 对应多个用户线程; 接下来针对上面这三种对应关系说明它们优缺点。先下图的 LWP 模型: LWP 模型 1 : 1 模式 一个线程对应到一个 LWP 再对应到一个内核线程,如上图的进程 4,属于此模型。 优点:实现并行,当一个 LWP 阻塞,不会影响其他 LWP; 缺点:每一个用户线程,就产生一个内核线程,创建线程的开销较大。 N : 1 模式 多个用户线程对应一个 LWP 再对应一个内核线程,如上图的进程 2,线程管理是在用户空间完成的,此模式中用户的线程对操作系统不可见。 优点:用户线程要开几个都没问题,且上下文切换发生用户空间,切换的效率较高; 缺点:一个用户线程如果阻塞了,则整个进程都将会阻塞,另外在多核 CPU 中,是没办法充分利用 CPU 的。 M : N 模式 根据前面的两个模型混搭一起,就形成 M:N 模型,该模型提供了两级控制,首先多个用户线程对应到多个 LWP,LWP 再一一对应到内核线程,如上图的进程 3。 优点:综合了前两种优点,大部分的线程上下文发生在用户空间,且多个线程又可以充分利用多核 CPU 的资源。 组合模式 如上图的进程 5,此进程结合 1:1 模型和 M:N 模型。开发人员可以针对不同的应用特点调节内核线程的数目来达到物理并行性和逻辑并行性的最佳方案。 调度 进程都希望自己能够占用 CPU 进行工作,那么这涉及到前面说过的进程上下文切换。 一旦操作系统把进程切换到运行状态,也就意味着该进程占用着 CPU 在执行,但是当操作系统把进程切换到其他状态时,那就不能在 CPU 中执行了,于是操作系统会选择下一个要运行的进程。 选择一个进程运行这一功能是在操作系统中完成的,通常称为调度程序(scheduler)。 那到底什么时候调度进程,或以什么原则来调度进程呢? 调度时机 在进程的生命周期中,当进程从一个运行状态到另外一状态变化的时候,其实会触发一次调度。 比如,以下状态的变化都会触发操作系统的调度: 从就绪态 -> 运行态:当进程被创建时,会进入到就绪队列,操作系统会从就绪队列选择一个进程运行; 从运行态 -> 阻塞态:当进程发生 I/O 事件而阻塞时,操作系统必须另外一个进程运行; 从运行态 -> 结束态:当进程退出结束后,操作系统得从就绪队列选择另外一个进程运行; 因为,这些状态变化的时候,操作系统需要考虑是否要让新的进程给 CPU 运行,或者是否让当前进程从 CPU 上退出来而换另一个进程运行。 另外,如果硬件时钟提供某个频率的周期性中断,那么可以根据如何处理时钟中断,把调度算法分为两类: 非抢占式调度算法挑选一个进程,然后让该进程运行直到被阻塞,或者直到该进程退出,才会调用另外一个进程,也就是说不会理时钟中断这个事情。 抢占式调度算法挑选一个进程,然后让该进程只运行某段时间,如果在该时段结束时,该进程仍然在运行时,则会把它挂起,接着调度程序从就绪队列挑选另外一个进程。这种抢占式调度处理,需要在时间间隔的末端发生时钟中断,以便把 CPU 控制返回给调度程序进行调度,也就是常说的时间片机制。 调度原则 原则一:如果运行的程序,发生了 I/O 事件的请求,那 CPU 使用率必然会很低,因为此时进程在阻塞等待硬盘的数据返回。这样的过程,势必会造成 CPU 突然的空闲。所以,为了提高 CPU 利用率,在这种发送 I/O 事件致使 CPU 空闲的情况下,调度程序需要从就绪队列中选择一个进程来运行。 原则二:有的程序执行某个任务花费的时间会比较长,如果这个程序一直占用着 CPU,会造成系统吞吐量(CPU 在单位时间内完成的进程数量)的降低。所以,要提高系统的吞吐率,调度程序要权衡长任务和短任务进程的运行完成数量。 原则三:从进程开始到结束的过程中,实际上是包含两个时间,分别是进程运行时间和进程等待时间,这两个时间总和就称为周转时间。进程的周转时间越小越好,如果进程的等待时间很长而运行时间很短,那周转时间就很长,这不是我们所期望的,调度程序应该避免这种情况发生。 原则四:处于就绪队列的进程,也不能等太久,当然希望这个等待的时间越短越好,这样可以使得进程更快的在 CPU 中执行。所以,就绪队列中进程的等待时间也是调度程序所需要考虑的原则。 原则五:对于鼠标、键盘这种交互式比较强的应用,我们当然希望它的响应时间越快越好,否则就会影响用户体验了。所以,对于交互式比较强的应用,响应时间也是调度程序需要考虑的原则。 五种调度原则 针对上面的五种调度原则,总结成如下: CPU 利用率:调度程序应确保 CPU 是始终匆忙的状态,这可提高 CPU 的利用率; 系统吞吐量:吞吐量表示的是单位时间内 CPU 完成进程的数量,长作业的进程会占用较长的 CPU 资源,因此会降低吞吐量,相反,短作业的进程会提升系统吞吐量; 周转时间:周转时间是进程运行和阻塞时间总和,一个进程的周转时间越小越好; 等待时间:这个等待时间不是阻塞状态的时间,而是进程处于就绪队列的时间,等待的时间越长,用户越不满意; 响应时间:用户提交请求到系统第一次产生响应所花费的时间,在交互式系统中,响应时间是衡量调度算法好坏的主要标准。 说白了,这么多调度原则,目的就是要使得进程要「快」。 调度算法 不同的调度算法适用的场景也是不同的。 接下来,说说在单核 CPU 系统中常见的调度算法。 01 先来先服务调度算法 最简单的一个调度算法,就是非抢占式的先来先服务(First Come First Severd, FCFS)算法了。 FCFS 调度算法 顾名思义,先来后到,每次从就绪队列选择最先进入队列的进程,然后一直运行,直到进程退出或被阻塞,才会继续从队列中选择第一个进程接着运行。 这似乎很公平,但是当一个长作业先运行了,那么后面的短作业等待的时间就会很长,不利于短作业。 FCFS 对长作业有利,适用于 CPU 繁忙型作业的系统,而不适用于 I/O 繁忙型作业的系统。 02 最短作业优先调度算法 最短作业优先(Shortest Job First, SJF)调度算法同样也是顾名思义,它会优先选择运行时间最短的进程来运行,这有助于提高系统的吞吐量。 SJF 调度算法 这显然对长作业不利,很容易造成一种极端现象。 比如,一个长作业在就绪队列等待运行,而这个就绪队列有非常多的短作业,那么就会使得长作业不断的往后推,周转时间变长,致使长作业长期不会被运行。 03 高响应比优先调度算法 前面的「先来先服务调度算法」和「最短作业优先调度算法」都没有很好的权衡短作业和长作业。 那么,高响应比优先 (Highest Response Ratio Next, HRRN)调度算法主要是权衡了短作业和长作业。 每次进行进程调度时,先计算「响应比优先级」,然后把「响应比优先级」最高的进程投入运行,「响应比优先级」的计算公式: 从上面的公式,可以发现: 如果两个进程的「等待时间」相同时,「要求的服务时间」越短,「响应比」就越高,这样短作业的进程容易被选中运行; 如果两个进程「要求的服务时间」相同时,「等待时间」越长,「响应比」就越高,这就兼顾到了长作业进程,因为进程的响应比可以随时间等待的增加而提高,当其等待时间足够长时,其响应比便可以升到很高,从而获得运行的机会; 04 时间片轮转调度算法 最古老、最简单、最公平且使用最广的算法就是时间片轮转(Round Robin, RR)调度算法。。 RR 调度算法 每个进程被分配一个时间段,称为时间片(Quantum),即允许该进程在该时间段中运行。 如果时间片用完,进程还在运行,那么将会把此进程从 CPU 释放出来,并把 CPU 分配另外一个进程; 如果该进程在时间片结束前阻塞或结束,则 CPU 立即进行切换; 另外,时间片的长度就是一个很关键的点: 如果时间片设得太短会导致过多的进程上下文切换,降低了 CPU 效率; 如果设得太长又可能引起对短作业进程的响应时间变长。将 通常时间片设为 20ms~50ms 通常是一个比较合理的折中值。 05 最高优先级调度算法 前面的「时间片轮转算法」做了个假设,即让所有的进程同等重要,也不偏袒谁,大家的运行时间都一样。 但是,对于多用户计算机系统就有不同的看法了,它们希望调度是有优先级的,即希望调度程序能从就绪队列中选择最高优先级的进程进行运行,这称为最高优先级(Highest Priority First,HPF)调度算法。 进程的优先级可以分为,静态优先级或动态优先级: 静态优先级:创建进程时候,就已经确定了优先级了,然后整个运行时间优先级都不会变化; 动态优先级:根据进程的动态变化调整优先级,比如如果进程运行时间增加,则降低其优先级,如果进程等待时间(就绪队列的等待时间)增加,则升高其优先级,也就是随着时间的推移增加等待进程的优先级。 该算法也有两种处理优先级高的方法,非抢占式和抢占式: 非抢占式:当就绪队列中出现优先级高的进程,运行完当前进程,再选择优先级高的进程。 抢占式:当就绪队列中出现优先级高的进程,当前进程挂起,调度优先级高的进程运行。 但是依然有缺点,可能会导致低优先级的进程永远不会运行。 06 多级反馈队列调度算法 多级反馈队列(Multilevel Feedback Queue)调度算法是「时间片轮转算法」和「最高优先级算法」的综合和发展。 顾名思义: 「多级」表示有多个队列,每个队列优先级从高到低,同时优先级越高时间片越短。 「反馈」表示如果有新的进程加入优先级高的队列时,立刻停止当前正在运行的进程,转而去运行优先级高的队列; 多级反馈队列 来看看,它是如何工作的: 设置了多个队列,赋予每个队列不同的优先级,每个队列优先级从高到低,同时优先级越高时间片越短; 新的进程会被放入到第一级队列的末尾,按先来先服务的原则排队等待被调度,如果在第一级队列规定的时间片没运行完成,则将其转入到第二级队列的末尾,以此类推,直至完成; 当较高优先级的队列为空,才调度较低优先级的队列中的进程运行。如果进程运行时,有新进程进入较高优先级的队列,则停止当前运行的进程并将其移入到原队列末尾,接着让较高优先级的进程运行; 可以发现,对于短作业可能可以在第一级队列很快被处理完。对于长作业,如果在第一级队列处理不完,可以移入下次队列等待被执行,虽然等待的时间变长了,但是运行时间也会更长了,所以该算法很好的兼顾了长短作业,同时有较好的响应时间。 看的迷迷糊糊?那我拿去银行办业务的例子,把上面的调度算法串起来,你还不懂,你锤我! 办理业务的客户相当于进程,银行窗口工作人员相当于 CPU。 现在,假设这个银行只有一个窗口(单核 CPU ),那么工作人员一次只能处理一个业务。 银行办业务 那么最简单的处理方式,就是先来的先处理,后面来的就乖乖排队,这就是先来先服务(FCFS)调度算法。但是万一先来的这位老哥是来贷款的,这一谈就好几个小时,一直占用着窗口,这样后面的人只能干等,或许后面的人只是想简单的取个钱,几分钟就能搞定,却因为前面老哥办长业务而要等几个小时,你说气不气人? 先来先服务 有客户抱怨了,那我们就要改进,我们干脆优先给那些几分钟就能搞定的人办理业务,这就是短作业优先(SJF)调度算法。听起来不错,但是依然还是有个极端情况,万一办理短业务的人非常的多,这会导致长业务的人一直得不到服务,万一这个长业务是个大客户,那不就捡了芝麻丢了西瓜 最短作业优先 那就公平起见,现在窗口工作人员规定,每个人我只处理 10 分钟。如果 10 分钟之内处理完,就马上换下一个人。如果没处理完,依然换下一个人,但是客户自己得记住办理到哪个步骤了。这个也就是时间片轮转(RR)调度算法。但是如果时间片设置过短,那么就会造成大量的上下文切换,增大了系统开销。如果时间片过长,相当于退化成退化成 FCFS 算法了。 时间片轮转 既然公平也可能存在问题,那银行就对客户分等级,分为普通客户、VIP 客户、SVIP 客户。只要高优先级的客户一来,就第一时间处理这个客户,这就是最高优先级(HPF)调度算法。但依然也会有极端的问题,万一当天来的全是高级客户,那普通客户不是没有被服务的机会,不把普通客户当人是吗?那我们把优先级改成动态的,如果客户办理业务时间增加,则降低其优先级,如果客户等待时间增加,则升高其优先级。 最高优先级(静态) 那有没有兼顾到公平和效率的方式呢?这里介绍一种算法,考虑的还算充分的,多级反馈队列(MFQ)调度算法,它是时间片轮转算法和优先级算法的综合和发展。它的工作方式: 多级反馈队列 银行设置了多个排队(就绪)队列,每个队列都有不同的优先级,各个队列优先级从高到低,同时每个队列执行时间片的长度也不同,优先级越高的时间片越短。 新客户(进程)来了,先进入第一级队列的末尾,按先来先服务原则排队等待被叫号(运行)。如果时间片用完客户的业务还没办理完成,则让客户进入到下一级队列的末尾,以此类推,直至客户业务办理完成。 当第一级队列没人排队时,就会叫号二级队列的客户。如果客户办理业务过程中,有新的客户加入到较高优先级的队列,那么此时办理中的客户需要停止办理,回到原队列的末尾等待再次叫号,因为要把窗口让给刚进入较高优先级队列的客户。 可以发现,对于要办理短业务的客户来说,可以很快的轮到并解决。对于要办理长业务的客户,一下子解决不了,就可以放到下一个队列,虽然等待的时间稍微变长了,但是轮到自己的办理时间也变长了,也可以接受,不会造成极端的现象,可以说是综合上面几种算法的优点。 好文推荐 真棒!20 张图揭开内存管理的迷雾,瞬间豁然开朗 唠叨唠叨 其实,关于进程和线程的部分,小林周末就已经写好了。 但是,写到调度算法的时候,我就懵逼了,在想用什么方式能更通俗易懂的表达这些晦涩难懂的算法,这一小结花了我非常多时间。唉,菜就是菜,小林我也不找借口了。。。 另外,最近小林创了技术交流群,里面的人说话又好听,各个都是人才,有兴趣的读者,可以扫一扫小林的私人微信二维码,备注「加群」即可。 扫一扫,进群 如果大家在阅读过程中,发现了不理解或有错误的地方,欢迎跟在底部留言,你们的每一条留言,小林都会回复。 小林是专为大家图解的工具人,Goodbye,我们下次见! 本文分享自微信公众号 - 小林coding(CodingLin)。如有侵权,请联系 support@oschina.cn 删除。本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

优秀的个人博客,低调大师

阿里云轻量应用服务器基础建站系统部署Web环境与应用

如果我们开始就接触阿里云主机产品的话,可能认识其中的ECS服务器和虚拟主机,目前又出来轻量应用服务器,这里我们不去分析其产品背后的配置以及架构,单单从产品本身应用上看轻量应用服务器比较偏向于建站用户的。比如在安装系统的时候可以选择无环境的系统镜像,也可以选择安装LAMP、WordPress、宝塔面板等环境自带系统。 其实在ECS服务器中也是可以安装的,直接在云市场中选择安装。老左不清楚阿里云出这款产品的目的是什么。其次,在轻量应用服务器面板中功能上比ECS服务器稍微简单一些。包括常规的系统安装、安全组、快照、磁盘管理。在这篇文章中,老左看看其自带的应用镜像如何操作和管理的。有需要的朋友可以提前领取优惠劵 第一、安装应用镜像 这里老左选择安装应用镜像,如果是安装系统镜像与我们熟悉的ECS没有什么区别。这里应用镜像包括直接安装WP、LAMP、Node.js、ECSHOP等常规CMS的直接安装。但是这里我还是安装宝塔面板。(看来宝塔最近几年发展还可以,都和云主机商捆绑 合作了) 这里看到我手上这测试机在重置安装。如果我们有重要数据需要提前备份,因为重新安装系统后已有数据是没有了的。 第二、设置防火墙安全组 这里在安装完毕之后发现原来系统的ROOT还是可以使用的,系统账户没有变,然后系统是安装了宝塔面板。当然,原来的数据也是没有了的。这里我们可能要想着去登录宝塔面板(因为这里我是安装的这个),但是无法登录。因为没有设置安全组将8888端口添加进去。 这里我们参考"阿里云轻量应用服务器设置防火墙规则放行端口方法"文章将需要的8888以及888端口添加进来。 第三、初始化面板账户 这里我们需要先登录SSH,或者是远程连接,输入命令初始化面板的密码。 这里可以看到我们的宝塔面板密码。复制密码,然后正常的去登录面板初始化。 看到这里是不是熟悉了?选择安装LNMP还是LAMP就可以了。完毕之后,就一个宝塔面板安装在阿里轻量应用服务器中,就如同我们在ECS服务器中安装一样。 第四、小结 1、阿里云轻量应用服务器相对ECS服务器而言,可视化界面操作比较多一些。(这里不去分析机器的区别)可以直接安装需要的镜像,以及可视化设置账户。 2、我们如果不喜欢自带镜像也可以自己安装一个精简版的系统,然后类似ECS服务器去部署。我们不要忽视安全组,如果不设置的话是无法访问的。同时还有快照工具可以使用。轻量服务器上的快照备份是免费的(目前是),快照可备份服务器数据,总快照数量上限为已创建实例数乘以3,但最多不超过15个。对于ECS服务器上快照是收费的。了解更多详细内容可点击查看哦

优秀的个人博客,低调大师

夯实Java基础系列22:一文读懂Java序列化和反序列化

本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到我的仓库里查看 https://github.com/h2pl/Java-Tutorial 喜欢的话麻烦点下Star哈 文章首发于我的个人博客: www.how2playlife.com 本文参考 http://www.importnew.com/17964.html和https://www.ibm.com/developerworks/cn/java/j-lo-serial/ 序列化与反序列化概念 序列化 (Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程。一般将一个对象存储至一个储存媒介,例如档案或是记亿体缓冲等。在网络传输过程中,可以是字节或是XML等格式。而字节的或XML编码格式可以还原完全相等的对象。这个相反的过程又称为反序列化。 Java对象的序列化与反序列化 在Java中,我们可以通过多种方式来创建对象,并且只要对象没有被回收我们都可以复用该对象。但是,我们创建出来的这些Java对象都是存在于JVM的堆内存中的。 只有JVM处于运行状态的时候,这些对象才可能存在。一旦JVM停止运行,这些对象的状态也就随之而丢失了。 但是在真实的应用场景中,我们需要将这些对象持久化下来,并且能够在需要的时候把对象重新读取出来。Java的对象序列化可以帮助我们实现该功能。 对象序列化机制(object serialization)是Java语言内建的一种对象持久化方式,通过对象序列化,可以把对象的状态保存为字节数组,并且可以在有需要的时候将这个字节数组通过反序列化的方式再转换成对象。 对象序列化可以很容易的在JVM中的活动对象和字节数组(流)之间进行转换。 在Java中,对象的序列化与反序列化被广泛应用到RMI(远程方法调用)及网络传输中。 相关接口及类 Java为了方便开发人员将Java对象进行序列化及反序列化提供了一套方便的API来支持。其中包括以下接口和类: java.io.Serializable java.io.Externalizable ObjectOutput ObjectInput ObjectOutputStream ObjectInputStream Serializable 接口 类通过实现 java.io.Serializable 接口以启用其序列化功能。 未实现此接口的类将无法使其任何状态序列化或反序列化。可序列化类的所有子类型本身都是可序列化的。序列化接口没有方法或字段,仅用于标识可序列化的语义。 (该接口并没有方法和字段,为什么只有实现了该接口的类的对象才能被序列化呢?) 当试图对一个对象进行序列化的时候,如果遇到不支持 Serializable 接口的对象。在此情况下,将抛出NotSerializableException。 如果要序列化的类有父类,要想同时将在父类中定义过的变量持久化下来,那么父类也应该集成java.io.Serializable接口。 下面是一个实现了java.io.Serializable接口的类 public class 序列化和反序列化 { public static void main(String[] args) { } //注意,内部类不能进行序列化,因为它依赖于外部类 @Test public void test() throws IOException { A a = new A(); a.i = 1; a.s = "a"; FileOutputStream fileOutputStream = null; FileInputStream fileInputStream = null; try { //将obj写入文件 fileOutputStream = new FileOutputStream("temp"); ObjectOutputStream objectOutputStream = new ObjectOutputStream(fileOutputStream); objectOutputStream.writeObject(a); fileOutputStream.close(); //通过文件读取obj fileInputStream = new FileInputStream("temp"); ObjectInputStream objectInputStream = new ObjectInputStream(fileInputStream); A a2 = (A) objectInputStream.readObject(); fileInputStream.close(); System.out.println(a2.i); System.out.println(a2.s); //打印结果和序列化之前相同 } catch (IOException e) { e.printStackTrace(); } catch (ClassNotFoundException e) { e.printStackTrace(); } } } class A implements Serializable { int i; String s; } Externalizable接口 除了Serializable 之外,java中还提供了另一个序列化接口Externalizable 为了了解Externalizable接口和Serializable接口的区别,先来看代码,我们把上面的代码改成使用Externalizable的形式。 class B implements Externalizable { //必须要有公开无参构造函数。否则报错 public B() { } int i; String s; @Override public void writeExternal(ObjectOutput out) throws IOException { } @Override public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { } } @Test public void test2() throws IOException, ClassNotFoundException { B b = new B(); b.i = 1; b.s = "a"; //将obj写入文件 FileOutputStream fileOutputStream = new FileOutputStream("temp"); ObjectOutputStream objectOutputStream = new ObjectOutputStream(fileOutputStream); objectOutputStream.writeObject(b); fileOutputStream.close(); //通过文件读取obj FileInputStream fileInputStream = new FileInputStream("temp"); ObjectInputStream objectInputStream = new ObjectInputStream(fileInputStream); B b2 = (B) objectInputStream.readObject(); fileInputStream.close(); System.out.println(b2.i); System.out.println(b2.s); //打印结果为0和null,即初始值,没有被赋值 //0 //null } 通过上面的实例可以发现,对B类进行序列化及反序列化之后得到的对象的所有属性的值都变成了默认值。也就是说,之前的那个对象的状态并没有被持久化下来。这就是Externalizable接口和Serializable接口的区别: Externalizable继承了Serializable,该接口中定义了两个抽象方法:writeExternal()与readExternal()。 当使用Externalizable接口来进行序列化与反序列化的时候需要开发人员重写writeExternal()与readExternal()方法。由于上面的代码中,并没有在这两个方法中定义序列化实现细节,所以输出的内容为空。 还有一点值得注意:在使用Externalizable进行序列化的时候,在读取对象时,会调用被序列化类的无参构造器去创建一个新的对象,然后再将被保存对象的字段的值分别填充到新对象中。所以,实现Externalizable接口的类必须要提供一个public的无参的构造器。 class C implements Externalizable { int i; int j; String s; public C() { } //实现下面两个方法可以选择序列化中需要被复制的成员。 //并且,写入顺序和读取顺序要一致,否则报错。 //可以写入多个同类型变量,顺序保持一致即可。 @Override public void writeExternal(ObjectOutput out) throws IOException { out.writeInt(i); out.writeInt(j); out.writeObject(s); } @Override public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { i = in.readInt(); j = in.readInt(); s = (String) in.readObject(); } } @Test public void test3() throws IOException, ClassNotFoundException { C c = new C(); c.i = 1; c.j = 2; c.s = "a"; //将obj写入文件 FileOutputStream fileOutputStream = new FileOutputStream("temp"); ObjectOutputStream objectOutputStream = new ObjectOutputStream(fileOutputStream); objectOutputStream.writeObject(c); fileOutputStream.close(); //通过文件读取obj FileInputStream fileInputStream = new FileInputStream("temp"); ObjectInputStream objectInputStream = new ObjectInputStream(fileInputStream); C c2 = (C) objectInputStream.readObject(); fileInputStream.close(); System.out.println(c2.i); System.out.println(c2.j); System.out.println(c2.s); //打印结果为0和null,即初始值,没有被赋值 //0 //null } 序列化ID 序列化 ID 问题情境:两个客户端 A 和 B 试图通过网络传递对象数据,A 端将对象 C 序列化为二进制数据再传给 B,B 反序列化得到 C。 问题:C 对象的全类路径假设为 com.inout.Test,在 A 和 B 端都有这么一个类文件,功能代码完全一致。也都实现了 Serializable 接口,但是反序列化时总是提示不成功。 解决:虚拟机是否允许反序列化,不仅取决于类路径和功能代码是否一致,一个非常重要的一点是两个类的序列化 ID 是否一致(就是 private static final long serialVersionUID = 1L)。清单 1 中,虽然两个类的功能代码完全一致,但是序列化 ID 不同,他们无法相互序列化和反序列化。 package com.inout; import java.io.Serializable; public class A implements Serializable { private static final long serialVersionUID = 1L; private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } package com.inout; import java.io.Serializable; public class A implements Serializable { private static final long serialVersionUID = 2L; private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } 静态变量不参与序列化 清单 2 中的 main 方法,将对象序列化后,修改静态变量的数值,再将序列化对象读取出来,然后通过读取出来的对象获得静态变量的数值并打印出来。依照清单 2,这个 System.out.println(t.staticVar) 语句输出的是 10 还是 5 呢? public class Test implements Serializable { private static final long serialVersionUID = 1L; public static int staticVar = 5; public static void main(String[] args) { try { //初始时staticVar为5 ObjectOutputStream out = new ObjectOutputStream( new FileOutputStream("result.obj")); out.writeObject(new Test()); out.close(); //序列化后修改为10 Test.staticVar = 10; ObjectInputStream oin = new ObjectInputStream(new FileInputStream( "result.obj")); Test t = (Test) oin.readObject(); oin.close(); //再读取,通过t.staticVar打印新的值 System.out.println(t.staticVar); } catch (FileNotFoundException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } catch (ClassNotFoundException e) { e.printStackTrace(); } } } 最后的输出是 10,对于无法理解的读者认为,打印的 staticVar 是从读取的对象里获得的,应该是保存时的状态才对。之所以打印 10 的原因在于序列化时,并不保存静态变量,这其实比较容易理解,序列化保存的是对象的状态,静态变量属于类的状态,因此 序列化并不保存静态变量。 探究ArrayList的序列化 ArrayList的序列化在介绍ArrayList序列化之前,先来考虑一个问题: 如何自定义的序列化和反序列化策略 带着这个问题,我们来看java.util.ArrayList的源码 public class ArrayList<E> extends AbstractList<E> implements List<E>, RandomAccess, Cloneable, java.io.Serializable { private static final long serialVersionUID = 8683452581122892189L; transient Object[] elementData; // non-private to simplify nested class access private int size; } 笔者省略了其他成员变量,从上面的代码中可以知道ArrayList实现了java.io.Serializable接口,那么我们就可以对它进行序列化及反序列化。 因为elementData是transient的(1.8好像改掉了这一点),所以我们认为这个成员变量不会被序列化而保留下来。我们写一个Demo,验证一下我们的想法: public class ArrayList的序列化 { public static void main(String[] args) throws IOException, ClassNotFoundException { ArrayList list = new ArrayList(); list.add("a"); list.add("b"); ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream("arr")); objectOutputStream.writeObject(list); objectOutputStream.close(); ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("arr")); ArrayList list1 = (ArrayList) objectInputStream.readObject(); objectInputStream.close(); System.out.println(Arrays.toString(list.toArray())); //序列化成功,里面的元素保持不变。 } 了解ArrayList的人都知道,ArrayList底层是通过数组实现的。那么数组elementData其实就是用来保存列表中的元素的。通过该属性的声明方式我们知道,他是无法通过序列化持久化下来的。那么为什么code 4的结果却通过序列化和反序列化把List中的元素保留下来了呢? writeObject和readObject方法 在ArrayList中定义了来个方法: writeObject和readObject。 这里先给出结论: 在序列化过程中,如果被序列化的类中定义了writeObject 和 readObject 方法,虚拟机会试图调用对象类里的 writeObject 和 readObject 方法,进行用户自定义的序列化和反序列化。 如果没有这样的方法,则默认调用是 ObjectOutputStream 的 defaultWriteObject 方法以及 ObjectInputStream 的 defaultReadObject 方法。 用户自定义的 writeObject 和 readObject 方法可以允许用户控制序列化的过程,比如可以在序列化的过程中动态改变序列化的数值。 来看一下这两个方法的具体实现: private void readObject(java.io.ObjectInputStream s) throws java.io.IOException, ClassNotFoundException { elementData = EMPTY_ELEMENTDATA; // Read in size, and any hidden stuff s.defaultReadObject(); // Read in capacity s.readInt(); // ignored if (size > 0) { // be like clone(), allocate array based upon size not capacity ensureCapacityInternal(size); Object[] a = elementData; // Read in all elements in the proper order. for (int i=0; i<size; i++) { a[i] = s.readObject(); } } } private void writeObject(java.io.ObjectOutputStream s) throws java.io.IOException{ // Write out element count, and any hidden stuff int expectedModCount = modCount; s.defaultWriteObject(); // Write out size as capacity for behavioural compatibility with clone() s.writeInt(size); // Write out all elements in the proper order. for (int i=0; i<size; i++) { s.writeObject(elementData[i]); } if (modCount != expectedModCount) { throw new ConcurrentModificationException(); } } 那么为什么ArrayList要用这种方式来实现序列化呢? why transient ArrayList实际上是动态数组,每次在放满以后自动增长设定的长度值,如果数组自动增长长度设为100,而实际只放了一个元素,那就会序列化99个null元素。为了保证在序列化的时候不会将这么多null同时进行序列化,ArrayList把元素数组设置为transient。 why writeObject and readObject 前面说过,为了防止一个包含大量空对象的数组被序列化,为了优化存储,所以,ArrayList使用transient来声明elementData。 但是,作为一个集合,在序列化过程中还必须保证其中的元素可以被持久化下来,所以,通过重写writeObject 和 readObject方法的方式把其中的元素保留下来。 writeObject方法把elementData数组中的元素遍历的保存到输出流(ObjectOutputStream)中。 readObject方法从输入流(ObjectInputStream)中读出对象并保存赋值到elementData数组中。 如何自定义的序列化和反序列化策略 延续上一部分,刚刚我们明白了ArrayList序列化数组元素的原理。 至此,我们先试着来回答刚刚提出的问题: 如何自定义的序列化和反序列化策略 答:可以通过在被序列化的类中增加writeObject 和 readObject方法。那么问题又来了: 虽然ArrayList中写了writeObject 和 readObject 方法,但是这两个方法并没有显示的被调用啊。 那么如果一个类中包含writeObject 和 readObject 方法,那么这两个方法是怎么被调用的呢? ObjectOutputStream从code 4中,我们可以看出,对象的序列化过程通过ObjectOutputStream和ObjectInputputStream来实现的,那么带着刚刚的问题,我们来分析一下ArrayList中的writeObject 和 readObject 方法到底是如何被调用的呢? 为了节省篇幅,这里给出ObjectOutputStream的writeObject的调用栈: writeObject ---> writeObject0 --->writeOrdinaryObject--->writeSerialData--->invokeWriteObject 这里看一下invokeWriteObject: void invokeWriteObject(Object obj, ObjectOutputStream out) throws IOException, UnsupportedOperationException { if (writeObjectMethod != null) { try { writeObjectMethod.invoke(obj, new Object[]{ out }); } catch (InvocationTargetException ex) { Throwable th = ex.getTargetException(); if (th instanceof IOException) { throw (IOException) th; } else { throwMiscException(th); } } catch (IllegalAccessException ex) { // should not occur, as access checks have been suppressed throw new InternalError(ex); } } else { throw new UnsupportedOperationException(); } } 其中writeObjectMethod.invoke(obj, new Object[]{ out });是关键,通过反射的方式调用writeObjectMethod方法。官方是这么解释这个writeObjectMethod的: class-defined writeObject method, or null if none 在我们的例子中,这个方法就是我们在ArrayList中定义的writeObject方法。通过反射的方式被调用了。 至此,我们先试着来回答刚刚提出的问题: 如果一个类中包含writeObject 和 readObject 方法,那么这两个方法是怎么被调用的? 答:在使用ObjectOutputStream的writeObject方法和ObjectInputStream的readObject方法时,会通过反射的方式调用。 为什么要实现Serializable 至此,我们已经介绍完了ArrayList的序列化方式。那么,不知道有没有人提出这样的疑问: Serializable明明就是一个空的接口,它是怎么保证只有实现了该接口的方法才能进行序列化与反序列化的呢? Serializable接口的定义: public interface Serializable { } 读者可以尝试把code 1中的继承Serializable的代码去掉,再执行code 2,会抛出java.io.NotSerializableException。 其实这个问题也很好回答,我们再回到刚刚ObjectOutputStream的writeObject的调用栈: writeObject ---> writeObject0 --->writeOrdinaryObject--->writeSerialData--->invokeWriteObject writeObject0方法中有这么一段代码: if (obj instanceof String) { writeString((String) obj, unshared); } else if (cl.isArray()) { writeArray(obj, desc, unshared); } else if (obj instanceof Enum) { writeEnum((Enum<?>) obj, desc, unshared); } else if (obj instanceof Serializable) { writeOrdinaryObject(obj, desc, unshared); } else { if (extendedDebugInfo) { throw new NotSerializableException( cl.getName() + "\n" + debugInfoStack.toString()); } else { throw new NotSerializableException(cl.getName()); } } 在进行序列化操作时,会判断要被序列化的类是否是Enum、Array和Serializable类型,如果不是则直接抛出NotSerializableException。 序列化知识点总结 1、如果一个类想被序列化,需要实现Serializable接口。否则将抛出NotSerializableException异常,这是因为,在序列化操作过程中会对类型进行检查,要求被序列化的类必须属于Enum、Array和Serializable类型其中的任何一种。 2、通过ObjectOutputStream和ObjectInputStream对对象进行序列化及反序列化 3、虚拟机是否允许反序列化,不仅取决于类路径和功能代码是否一致,一个非常重要的一点是两个类的序列化 ID 是否一致(就是 private static final long serialVersionUID) 序列化 ID 在 Eclipse 下提供了两种生成策略,一个是固定的 1L,一个是随机生成一个不重复的 long 类型数据(实际上是使用 JDK 工具生成),在这里有一个建议,如果没有特殊需求,就是用默认的 1L 就可以,这样可以确保代码一致时反序列化成功。那么随机生成的序列化 ID 有什么作用呢,有些时候,通过改变序列化 ID 可以用来限制某些用户的使用。 4、序列化并不保存静态变量。 5、要想将父类对象也序列化,就需要让父类也实现Serializable 接口。 6、Transient 关键字的作用是控制变量的序列化,在变量声明前加上该关键字,可以阻止该变量被序列化到文件中,在被反序列化后,transient 变量的值被设为初始值,如 int 型的是 0,对象型的是 null。 7、服务器端给客户端发送序列化对象数据,对象中有一些数据是敏感的,比如密码字符串等,希望对该密码字段在序列化时,进行加密,而客户端如果拥有解密的密钥,只有在客户端进行反序列化时,才可以对密码进行读取,这样可以一定程度保证序列化对象的数据安全。 8、在类中增加writeObject 和 readObject 方法可以实现自定义序列化策略 参考文章 https://blog.csdn.net/qq_34988624/article/details/86592229 https://www.meiwen.com.cn/subject/slhvhqtx.html https://blog.csdn.net/qq_34988624/article/details/86592229 https://segmentfault.com/a/1190000012220863 https://my.oschina.net/wuxinshui/blog/1511484 https://blog.csdn.net/hukailee/article/details/81107412 微信公众号 Java技术江湖 如果大家想要实时关注我更新的文章以及分享的干货的话,可以关注我的公众号【Java技术江湖】一位阿里 Java 工程师的技术小站,作者黄小斜,专注 Java 相关技术:SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程,偶尔讲点Docker、ELK,同时也分享技术干货和学习经验,致力于Java全栈开发! Java工程师必备学习资源: 一些Java工程师常用学习资源,关注公众号后,后台回复关键字 “Java” 即可免费无套路获取。 个人公众号:黄小斜 作者是跨考软件工程的 985 硕士,自学 Java 两年,拿到了 BAT 等近十家大厂 offer,从技术小白成长为阿里工程师。 作者专注于 JAVA 后端技术栈,热衷于分享程序员干货、学习经验、求职心得和程序人生,目前黄小斜的CSDN博客有百万+访问量,知乎粉丝2W+,全网已有10W+读者。 黄小斜是一个斜杠青年,坚持学习和写作,相信终身学习的力量,希望和更多的程序员交朋友,一起进步和成长! 关注公众号【黄小斜】后回复【原创电子书】即可领取我原创的电子书《菜鸟程序员修炼手册:从技术小白到阿里巴巴Java工程师》 程序员3T技术学习资源: 一些程序员学习技术的资源大礼包,关注公众号后,后台回复关键字 “资料” 即可免费无套路获取。

优秀的个人博客,低调大师

Python零基础学习代码实践 —— 打印5位数的回文数并统计个数

代码: num = 10000 sum = 0 while num <= 99999: a = num % 10 b = num // 10000 c = num % 1000 // 10 d = (num - (num//10000)*10000)//1000 if a == b and c == d: print(num) sum += 1 num += 1 print("5位数的回文数个数为:"sum) 执行结果: 10001 11011 12021 13031 14041 15051 16061 17071 18081 19091 20002 21012 22022 23032 24042 25052 26062 27072 28082 29092 30003 31013 32023 33033 34043 35053 36063 37073 38083 39093 40004 41014 42024 43034 44044 45054 46064 47074 48084 49094 50005 51015 52025 53035 54045 55055 56065 57075 58085 59095 60006 61016 62026 63036 64046 65056 66066 67076 68086 69096 70007 71017 72027 73037 74047 75057 76067 77077 78087 79097 80008 81018 82028 83038 84048 85058 86068 87078 88088 89098 90009 91019 92029 93039 94049 95059 96069 97079 98089 99099 5位数的回文数个数为: 90

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册