刚刚阅读在这里，点击刷新
刚刚阅读在这里，点击刷新
学历成了当今社会衡量一个人能力的标准之一，未来只会越来越深入。
我为什么又想聊 T 型人才呢？是因为我觉得 T 型人才和全栈不一样。
近来工作不在状态，烦躁，没事就写点东西扯扯淡吧。我知道其实还是很多人喜欢看扯淡的。
《程序员》杂志
我们请来 AI 技术一线的专家，请他们从实践的角度来解析 AI 领域各技术岗位的合格工程师都是怎样炼成的。
这个栏目将帮助大家筛选出人工智能和机器学习领域，每年各大顶级会议和研讨班上有意思的论文，解读出论文的核心思想，为精读提供阅读指导。
本期我们梳理了2017年区块链发展现状，从关键技术原理与实际应用出发，带你深入浅出探索区块链技术的方方面面。
16个主题，200余篇文章，180万字——不容错过的前沿技术、工具尽在其中，亲历者领域案例剖析
北京·中关村软件园微服务架构之基于容器编排的Dev/Ops流程
阅读&279 收藏&0
推荐：[Nginx以前对session保持支持不太好，主要采用ip_hash把同一来源的客户(同一C段的IP)固定指向后端的同一台机器，ip_hash有个缺点是不能实现很好的负载均衡；直到nginx的扩
我们整个 DevOps 流程是建立在容器编排的基础上的，目的是简化流程和实现自动化 CI/CD 和自动化运维。当中会有很多没有想到的地方，可能也不太适用于复杂场景。
随着 DevOps 和 SRE 概念的流行，越来越多的 developer 和 operater 们摒弃传统的开发部署流程，转向了如下图所示的无线循环模式：
在我理解 DevOps 包含三个大块：敏捷开发（Agile）、持续集成与交付（CI/CD）、自动运维（ITSM）。
在容器化的时代，我们是如何实现 DepOps 或者 SRE 的呢？下面我就来分享一下沪江学习产品线团队基于容器编排的 DevOps 流程。
大道至简，所有血的教训告诉我们，不要把简单的事情复杂化。换句话说，不要用复杂的方法处理简单的事情。我对敏捷的理解是「快」和「微」。快指迭代快，开发快，上线快，性能快。微指微服务、微镜像。围绕这两点，在开发阶段我们需要做以下几件事：
应用微服务化
这是个比较大的概念，不在这里讨论，有兴趣可以参考我的其他文章。但只有应用小了，才有可能快起来。
给 Docker 镜像瘦身
为了让 Docker 启动和运行得快，首先就是要对 Docker 瘦身。由于所有的应用全部会统一为 Java 语言开发，所以我们以 Java 为例，选用了 jre-alpine 作为我们的基础镜像，下面是 Dockerfile 的例子：
使用上述 Dockerfile 生成的镜像平均只有 80 多 MB，启动时间几乎在 5 秒内。使用 Alpine 镜像虽然减小了体积，但缺少一些工具命令，例如 curl 等，可以根据需要酌情安装。另外遇到的一个坑是时区问题：由于 Docker 镜像内的时区是 UTC 时间，和宿主机的东 8 区不一致，所以必须安装 timezone 工具并设置 TZ，才能使容器内时间和宿主机保持一致，对数据库的写入和日志的输出都是非常必要的一环。
把所有环境配置包含在镜像中
早在虚拟机时代，我们已经做到了使用包含依赖的虚拟机镜像来加速部署，那么为什么要止步于此呢？我们可以更进一步，把服务本身也包含在镜像中，Docker 用了更轻量的方式已经实现了这一点。
这里我们还要介绍一个概念，要让制作的镜像，能在所有安装了 Docker 的服务器上运行，而不在乎宿主机的操作系统及环境。借用 Java 的一句话来说：一次制作，多平台运行。所以，我们还会把所有环境的配置文件，以不同的文件名全部放入镜像中，通过参数来选择 Docker 启动时使用的环境配置文件。
值得注意的是，如果开发的应用是基于 Spring 框架的话，这个功能很好实现。但如果是其他语言开发，会有一定的开发量。
本文以默认 Java 开发当所有的开发工作完成后，推荐程序目录结构是这样的：
持续集成与交付
自动化的持续集成和交付在整个 DevOps 流中起了重要的角色，他是衔接开发和运维的桥梁。如果这一环做的不好，无法支撑大量微服务的快速的迭代和高效运维。在这一环节，我们需要灵活的运用工具，尽量减少人参与，当然仍然需要围绕「快」和「微」做文章。
如何减少人工参与到持续集成与持续交付呢？我们最希望的开发过程是：对着计算机说出我们的想要的功能，计算机按照套路，自动编码，自动发布到测试环境，自动运行测试脚本，自动上线。当然，目前时代要实现自动编码的过程还需要发明那只「猫」。
但只要对测试有足够信心，我们完全可以实现一种境界：在炎热的下午，轻松地提交自己编写的代码，去休息室喝杯咖啡，回来后看见自己的代码已经被应用在生产环境上了。在容器时代，我们可以很快速的实现这一梦想，其具体步骤如下图：
Gitfolw 与 Anti-Gitflown
持续集成的第一步是提交代码（Code Commit），VCS 也由 CVS，SVN 进化到如今的 Git，自然不得不说一下 Gitflow。谈起无人不晓的 Gitflow，大家一定会大谈其优点：支持多团队，设置多国家的开发人员并行开发，减小代码冲突或脏代码的上线概率。它的大致流程如下：
Gitflow 给我们展示了复杂团队在处理不通代码版本的优雅解决方案，它需要feature、develop、release、hotfix、master 5 条分支来处理不同时段的并行开发。但这真的合适于一个不超过 20 人的本地合作团队开发吗？我们的开发团队不足 6 人，每个人负责 3 个以上的微服务，几乎不可能在同个项目上安排两个以上的同学并行开发。
在初期我们准守规定并使用标准的 Gitflow 流程，开发人员立刻发现一个问题，他们需要在至少 3 条分支上来回的 merge 代码，且不会有任何代码冲突（因为就一个人开发），降低了开发的效率。这让我意识到，Gitflow 模式也许并不适合于小团队微服务的世界，一种反 Gitflow 模式的想法出现在脑海中。我决定对Gitflow 进行瘦身，化繁至简。
我们把 5 条分支简化为 3 条分支，其中 Master 分支的作用只是维护了最新的线上版本的作用，Dev 分支为开发的主要分支，所有的镜像是以此分支的代码为源头生成的。这时开发的过程变为：
开发人员从 Dev 分支中 checkout 新的 feature 分支，在 feature 分支上进行开发
当开发完成后 merge 回 Dev 分支中，根据 Dev 分支的代码打成镜像，部署 QA 环境交给 QA 人员测试
测试中如有 bug 便在新分支中修复问题循环步骤 2
测试完成 merge 回 Master 分支
如此一来，只有从 Feature 把代码 merge 到 Dev 分支的一次 merge 动作，大大提升可开发效率。
使用Jenkins Pipeline
Jenkins 作为老牌 CI/CD 工具，能够帮我们自动化完成代码编译、上传静态代码分析、制作镜像、部署测试环境、冒烟测试、部署上线等步骤。尤其是Jenkins 2.0 引入 Pipeline 概念后，以上步骤变的如此行云流水。它让我们从步骤 3 开始，完全可以无人值守完成整个集成和发布过程。
工欲善其事必先利其器，首先我们必须要在 Jenkins 上安装插件 ：
Pipeline Plugin（如果使用Jenkins2.0默认安装）
Sonar Scaner
Docker Pipeline Plugin
如果你第一次接触 Jenkins Pipeline，可以从 ... AL.md找到帮助。
现在，我们开始编写 Groove 代码。基于容器编排的 Pipeline 分为如下几个步骤：
1、检出代码
这个步骤使用 Git 插件，把开发好的代码检出。
2、Maven 构建 Java 代码
由于我们使用的是 Spring Boot 框架，生成物应该是一个可执行的 jar 包。推荐：[各个维度总结电商平台中的高并发高可用的架构实践，从架构设计的理念到平台的逻辑架构，以及到平台架构中各个模块的介绍]
3、静态代码分析
通过 Sonar Scaner 插件，通知 Sonar 对代码库进行静态扫描。
4、制作 Docker 镜像
此步骤会调用 Docker Pipeline 插件通过预先写好的 Dockerfile，把 jar 包和配置文件、三方依赖包一起打入 Docker 镜像中，并上传到私有 Docker 镜像仓库中。
5、部署测试环境
通过事先写好的部署文件，用 Marathon 插件通知 Marathon 集群，在测试环境中部署生成好的镜像。
6、自动化测试
运行事先测试人员写好的自动化测试脚本来检验程序是否运行正常。
7、人工测试
如果对自动化测试不放心，此时可选择结束 Pipeline，进行人工测试。为了说明整个流程，我们这里选择跳过人工测试环节。
8、部署生产环境
当所有测试通过后，Pipeline 自动发布生产环境。
最后我们来看看整个 Pipeline 的过程：
容器编排配置文档化
在介绍敏捷开发时，曾介绍过根据不同环境的配置参数部署到不同的环境。如何告知部署程序用什么样的配置文件启动服务，每个环境又用多少 CPU，内存和 instance 呢？
下面我们就来介绍一下容器编排的配置文件。由于我们使用 Mesos+Marathon的容器编排方式，部署的重任从以前的写部署脚本变成了写一个 Marathon 的配置，其内容如下：
&id&: &/appName&,
&cpus&: 2,
&mem&: 2048.0,
&instances&: 2,
&--spring.profiles.active=qa&
&labels&: {
&HAPROXY_GROUP&: &external&,
&HAPROXY_0_VHOST&: &xxx.hujiang.com&
&container&: {
&type&: &DOCKER&,
&docker&: {
&image&: &imageName&,
&network&: &USER&,
&forcePullImage&: true,
&portMappings&: [
&containerPort&: 12345,
&hostPort&: 0,
&protocol&: &tcp&,
&servicePort&: 12345} ]
&volumes&: [
&containerPath&: &/app/log&,
&hostPath&: &/home/logs/appName&,
&mode&: &RW& }]},
&ipAddress&: {
&networkName&: &calico-net&
&healthChecks&: [
&gracePeriodSeconds&: 300,
&ignoreHttp1xx&: true,
&intervalSeconds&: 20,
&maxConsecutiveFailures&: 3,
&path&: &/health_check&,
&portIndex&: 0,
&protocol&: &HTTP&,
&timeoutSeconds&: 20
&file:///etc/docker.tar.gz&
我们把这个配置内容保存为不同的 Json 文件，每个对应的环境都有一套配置文件。例如 Marathon-qa.json，Marathon-prod.json。当 Pipeline 部署时，可以通过Jenkins Marathon 插件，根据选择不同的环境，调用部署配置，从而达到自动部署的目的。
自动化流程和部署上线分离与管理
开发部署如此的简单快捷，是不是每个人都能方便的使用呢？答案是否定的，并不是因为技术上有难度，而是在于权限。在理想的情况下，通过这套流程的确可以做到在提交代码后，喝杯咖啡的时间就能看见自己的代码已经被千万用户使用了。
但风险过大，我们并不是每个人都能像 Rambo 一样 bug 的存在，大多数的情况还需要使用规范和流程来约束。就像自动化测试取代不了人工黑盒测试一样，部署测试后也不能直接上生产环境，在测试通过后还是需要有个人工确认和部署生产的过程。
所以我们需要把自动化流程和最后的部署上线工作分开来，分别变成两个 Job，并给后者单独分配权限，让有权限的人来做最后的部署工作。这个人可以是 Team leader、开发经理，也可以是运维伙伴，取决于公司的组织结构。
那这个部署的 Job 具体干什么呢？在容器编排时代，结合镜像既构建物的思想，部署 Job 不会从代码编译开始工作，而是把一个充分测试且通过的镜像版本，通过 Marathon Plugin 部署到产线环境中去。这里是 Deploy_only 的例子：
node('docker-qa'){
if (ReleaseVersion ==&&){
echo &发布版本不能为空&
stage &Prepare image&
def moduleName = &${ApplicationModule}&.toLowerCase()
def resDockerImage = imageName + &:latest&
def desDockerImage = imageName + &:${ReleaseVersion}&
if (GenDockerVersion ==&true&){
sh &docker pull ${resDockerImage}&
sh &docker tag ${resDockerImage} ${desDockerImage}&
sh &docker push ${desDockerImage}&
sh &docker rmi -f ${resDockerImage} ${desDockerImage}&
stage &Deploy on Mesos&
git branch: 'dev', changelog: false, credentialsId: 'deploy-key', url: 'git@gitlab.xxx.com:lms/xxx-test.git'
//Get the right marathon url
echo &DeployDC: & + DeployDC
marathon_url = &&
if (DeployDC==&AA&) {
if (DeployEnv == &prod&){
input &Are you sure to deploy to production?&
marathon_url = &${marathon_AA_prod}&
}else if (DeployEnv == &yz&) {
marathon_url = &${marathon_AA_yz}&
}else if (&${DeployDC}&==&BB&){
if (&${DeployEnv}& == &prod&){
input &Are you sure to deploy to production?&
marathon_url = &${marathon_BB_prod}&
}else if (&${DeployEnv}& == &yz&) {
marathon_url = &${marathon_BB_yz}&
marathon docker: imageName, dockerForcePull: true, forceUpdate: true, url: marathon_url, filename: &${DeployEnv}-deploy.json&
为什么不把这个文件跟随应用项目一起放到 scripts 下呢？因为把部署和应用分开后，可以由两拨人进行维护，兼顾公司的组织架构。
自动化运维
在 DevOps 的最后阶段是运维阶段。在容器时代，如何对庞大的镜像制品进行运维呢？我们的目标是尽量实现自动化运维，这里主要讲述两点：
容器的监控
容器的监控大致有两种方式：物理机上安装其他服务监控本机上的所有容器；通过 Mesos 或 Kubernates 自带 API 监控容器状态。两种方式其实都需要在物理机上安装相应的监控软件或 Agent。
在我们团队目前使用 cAdvisor + InfluxDB + Grafana 的组合套件实现对容器的监控。
首先需要在 Mesos 集群中所有的 Agent 安装 cAdvisor 。他负责把宿主机上所有运行中的容器数据以数据点（data point）形式发送给时序数据库（InfluxDB），下面是 cAdvisor 监控的一些数据点：
这些数据点经过 Grafana 整理，展示在界面上，这样我们就能掌握具体容器的性能指标了。下面是一个 Grafana 的截图：
除了对容器本身的监控，宿主机的监控也是必不可少的。由于监控的点有很多，这里不一一例举。
有了监控指标只是实现了自动化运维的第一步，当业务请求发生大量增加或减少，通过人工监测是不能及时的进行相应的，况且还不一定有那么多的人，7&24 小时的监控。一定需要有一套根据监控数据自行伸缩容的机制。在学习产品线，我们针对容器编排的 Mesos+Marathon 框架，开发了一套针对应用本身的自动扩容微服务。其原理如下：
通过 Restful 的接口通知 AutoScaler 程序需要监控的应用服务。
AutoScaler 程序开始读取每台 Agent 上部署相关应用的 Metrics 数据，其中包括 CPU，内存的使用状况。
当发现有应用过于繁忙（其表现形式大多是 CPU 占用过高或内存占用过大）时调用 Marathon API 将其扩容
Marathon 收到消息后，立刻通知 Mesos 集群发布新的应用，从而缓解当前的繁忙状况。
DevOps 和 SRE 并不是一个渴望而不可及的概念，它们需要在不同的环境中落地。我们整个 DevOps 流程是建立在容器编排的基础上的，目的是简化流程和实现自动化 CI/CD 和自动化运维。当中会有很多没有想到的地方，可能也不太适用于复杂场景。其次，本文中的例子也做了相应的隐私处理，可能无法直接使用。希望大家能通过我们在实践中产生的成功和遇到的问题，提炼出适合自己的 DevOps 流程。推荐：[
IoC容器的概念
IoC容器就是具有依赖注入功能的容器，IoC容器负责实例化、定位、配置应用程序中的对象及建立这些对象间的依赖。应用程序无需直接在代码中new相
请输入账号
请输入密码
&下次自动登录
第三方登录
请输入邮箱
请输入密码
请输入姓名或常用昵称
同意并接受
简短推荐语
为了正常使用评论、审核、关注等功能，请激活您的账号。
您的 Email：
激活邮件已发送，请注意查收（注意检查回收站、垃圾箱中是否有激活邮件）
如果仍未收到，请尝试
，如碰到困难请6. 临界区是指并发进程中访问共享变量的()段. A,管理信息 B,信息存储 C,数据 D,程序_百度知道
6. 临界区是指并发进程中访问共享变量的()段. A,管理信息 B,信息存储 C,数据 D,程序
我有更好的答案
D.程序 临界区是指并发进程中访问共享变量的(程序)段
采纳率：100%
四、程序与算法(共10分)设有一缓冲池P.文件系统中分配存储空间的基本单位不是记录。 ( F )2.具有多道功能的操作系统一定是多用户操作系统。( T )3，共10分)( T )1、最高响应比优先 ).若信号量S的初值定义为10; } }五:= p[out]; out := (out+1) mod 20、输出井组成、进程，从就绪队列中按一定的调度策略选择一个进程占用CPU 4.支持程序浮动的地址转换机制是( A、动态重定位 )5、资源利用率高、系统的开销较小。 ( F )5.文件系统中源程序是有结构的记录式文件、( 不可再现性 )和独立性、多级目录 )。15、索引文件 D、流式文件 12.文件系统的主要目的是(A、2。 7.当进程因时间片用完而让出处理机时：将独占设备改造为共享设备。它由专门负责I/O的常驻内存进程以及输入.UNIX中的文件系统采用(、P3、P4、有环不一定死锁 D.SPOOLing系统实现设备管理的虚拟技术、填空题(每空2分，共20分)1、1。14.为了允许不同用户的文件具有相同的文件名，通常在文件系统中采用(B、问答题(共16分)某系统有A、B、C、D四类资源可供五个进程P1、P2; wait(empty); wait(mutex)、破坏 C、窃取 D。( F )6.即使在多道程序环境下; in := (in+1) mod 20; signal(mutex)，它最靠近硬件。( F )10.若系统中存在一个循环等待的进程集合，则必定会死锁。在并发执行中，一个进程要等待其合作伙伴发来消息。17.两个进程合作完成一个任务。16.一种既有利于短小作业又兼顾到长作业的作业调度算法是( C; } }void Consumer(){ while(ture){ wait(full); wait(mutex)、3，即、4.程序并发执行时的特征是( 间断性 )、( 失去了封闭性 )、( 互斥 )和描述前趋关系、删除9.信号量被广泛用于三个目的是( 同步 )。进程对资源的需求和分配情况如下：按银行家算法回答下列问题：(1)现在系统中的各类资源还剩余多少、被锁者一定全在环中19.若系统中有五个并发进程涉及某个相同的变量A，则在S上调用了16次P操作和15次V操作后S的值应该为( 9 )。2.进程调度的方式通常有(抢占 )和(非抢占)两种方式。3.每个索引文件都必须有一张( 索引结点 )表，其中的地址登记项用来指出文件在外存上的位置信息。4.在一请求分页系统中，假如一个作业的页面走向为; signal(full)，另有一个输出进程将P中数据取出并输出。若讲程每次操作均以一个缓冲区为单位，试用记录型信号量写出两个进程的同步算法,要求写出信号量的初值、2。( F )9.系统调用是操作系统与外界程序之间的接口，它属于核心程序。在层次结构设计中.当每类资源只有一个个体时，下列说法中不正确的是( )。A、有环必死锁 B、死锁必有环C、4，则变量A的相关临界区是由( d )临界区构成。A、2个 B、网状文件 C、索引文件 D。6; void Producer(){ while(ture){producer an item in nextp：4、记录式文件 C，当分配给该作业的物理块数为4时(开始时没有装入页面)，采用LRU页面淘汰算法将产生( 8 )次缺页中断、C类12个、同步 )。18; p[in] .在多进程的并发系统中，肯定不会因竞争(C、CPU )而产生死锁、B类14个，P中含有20个可用缓冲区，一个输入进程将外部数据读入P、3个 C、4个 D。 三、判断题(每题1分.虚拟存储器是由操作系统提供的一个假想的特大存储器，它并不是实际的内存，其大小可比内存空间大得多、5、P5共享。系统对这四类资源的拥有量为:A类3个、D类12个，该进程应转变为( b )状态。A、等待 B，首先要考虑的是( 系统效率和吞吐量 ); signal(mutex); signal(empty)、流式文件 11。5、输出操作实际上是由(B:= nextp、实现对文件的按名存取 )。 13.文件系统中用( D、目录 )管理文件、就绪 C、运行 D一、单项选择题(每题1分。 解：semaphore mutex=1; semaphore empty=20; semaphore full=0; int in,out = 0; item p [20]、流式文件 )。A、网状文件 B、5个10.按逻辑结构划分，文件主要有两类：(记录式文件 )和流式文件。 A.数据文件存放在到存储介质上时，采用的逻辑组织形式是与(A、文件逻辑结构 )有关的。20，原始操作系统，操作系统2.用户程序中的输入.操作系统的发展过程是( C )C、管理程序; nextc ，普通用户也能设计用内存物理地址直接访问内存的程序。 ( F )7.顺序文件适合建立在顺序存储设备上、完成 8.文件的保密是指防止文件被( c )。A、篡改 B、3.在单处理器的多进程系统中，进程什么时候占用处理器和能占用多长时间，取决于(B、进程自身和进程调度策略 )。 二、操作系统 )完成。3.进程调度的对象和任务分别是( C )，而不适合建立在磁盘上。( T )8?(4分) (2)现在系统是否处于安全状态?为什么?(6分)(3)如果现在进程P2提出需要A类资源0个、B类资源4个、C类资源2个和D类资源0个，系统能否去满足它的请求?请说明原因。(6)(1)A：1;B：5;C：2;D：0 (2)need矩阵为：P1 0 0 0 0 P2 0 7 5 0 P3 1 0 0 2 P4 0 0 2 0 P5 0 6 4 2存在安全序列，如P1，P3，P4，P5，P2，所以安全(3)能，因为试探分配后，可用资源为1，1，0，0。可找到安全序列，所以可分配。六、计算题(第1题6分;第2题10分;第3题8分;共24分)1、某虚拟存储器的用户编程空间共32个页面，每页为1KB，内存为16KB。假定某时刻一用户页表中已调入内存的页面的页号和物理块号的对照表如下：则逻辑地址0A5D(H)所对应的物理地址是什么?(6分)0A5D(H)=01 11012号页对应4号块，所以物理地址是01 1101即125D(H)。2、设有三道作业，它们的提交时间及执行时间由下表给出:作业号 提交时间 执行时间1 8.5 2.02 9.2 1.63 9.4 0.5试计算在单道程序环境下，采用先来先服务调度算法和最短作业优先调度算法时的平均周转时间 (时间单位:小时，以十进制进行计算;要求写出计算过程)(10分)FCFS: 作业号 提交时间 执行时间 开始时间 完成时间 周转时间1 8.5 2.0 8.5 10.5 2.02 9.2 1.6 10.5 12.1 2.93 9.4 0.5 12.1 12.6 3.2平均周转时间=(2.0+2.9+3.2)/3=2.7(小时)SJF: 作业号 提交时间 执行时间 开始时间 完成时间 周转时间1 8.5 2.0 8.5 10.5 2.02 9.2 1.6 11.0 12.6 3.43 9.4 0.5 10.5 11.0 1.6平均周转时间=(2.0+3.4+1.6)/3=2.3(小时)3、假定当前磁头位于100号磁道，进程对磁道的请求序列依次为55，58，39，18，90，160，150，38，180。当采用先来先服务和最短寻道时间优先算法时，总的移动的磁道数分别是多少?(请给出寻道次序和每步移动磁道数)(8分)FCFS: 服务序列依次为:55，58，39，18，90，160，150，38，180移动的磁道数分别是: 45, 3, 19, 21, 72, 70, 10, 112,142总的移动的磁道数是:494SSTF: 服务序列依次为:90，58，55，39，38，18，150，160，180移动的磁道数分别是: 10, 32, 3, 16, 1, 20, 132, 10, 20总的移动的磁道数是:244。C、3，共20分) 1。( T )4.批处理系统的(主要优点)是系统的吞吐量大.在可变分区存储管理中，最优适应分配算法要求对空闲区表项按(C、尺寸从小到大)进行排列。6.设计批处理多道系统时，或者建立某个条件后再向前执行，这种制约性合作关系被称为进程的( B、5、1、记录式文件 B
为您推荐：
其他类似问题
临界区的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。&&&&&&&&&&&&&&&&&&
posts - 178,comments - 30,trackbacks - 0
1、操作系统分类
批处理操作系统、分时操作系统（Unix）、实时操作系统、网络操作系统、分布式操作系统、微机操作系统（Linux、Windows、IOS等）、嵌入式操作系统。
2、操作系统的4个特征：并发性、共享性、虚拟性、不确定性。
3、操作系统的功能有：处理机管理、文件管理、存储管理、设备管理、作业管理。
处理机管理：也称进程管理。实质上是对处理机执行时间进行管理，采用多道程序等技术将CPU的时间真正合理地分配给每个任务。主要包括进程管理、进程同步、进程通信和进程调度。
文件管理：又称信息管理。主要包括文件存储空间管理、目录管理、文件的读写管理和存取管理。
存储管理：是对主存储器空间的管理。主要包括存储分配与回收、存储保护、地址映射（变换）和主存扩充。（即内存管理）
设备管理：实质上是对硬件设备进行管理，其中包括输入输出设备的分配、启动、完成和回收。
作业管理：包括人物、人机交互和用户界面管理等。
4、处理机管理
1、程序顺序执行的特征：
顺序性：每一操作必须在下一操作开始之前结束
封闭性：程序运行时独占全机资源，资源的状态（除初始状态外）只有本程序才能改变，程序一旦执行，其结果不受外界影响
可再现性：程序执行环境和初始条件相同，重复执行时，结果相同
2、程序并发执行的特征：
间断性：程序并发运行时，共享系统资源，为完成同一任务相互合作，会形成相互制约关系，导致并发程序具有&执行-暂停-执行&这种间断性的活动规律
失去封闭性：程序并发执行时，资源状态由多个程序改变，某程序执行时，会受到其他程序影响，失去封闭性
不可再现性：失去封闭性，导致失去可再现性
3、进程的特征
结构特征：程序段、相关数据段和PCB三部分构成进程实体
动态性：进程实体的一次执行过程，具有生命期，而程序是有序指令集合，是静态的
并发性：多个进程同时存于内存，在一段时间内同时运行
独立性：进程实体是一个能独立运行、独立分配资源和独立接受调度的基本单位
异步性：进程按各自独立的、不可预知的速度向前推进
4.进程的状态：三态模型（左图）、五态模型（右图）
5、进程间的通信（同步与互斥）：由于多个进程可以并发执行，所以进程间必然存在资源共享和相互合作的问题。进程通信是指各个进程交换信息的过程。
　　　　同步是合作进程间直接制约问题，互斥是申请临界资源进程间的间接制约问题。（临界资源（Critical Resource, CR）：在同一时间只能供一个进程使用的资源）临界区管理4条原则：
有空即进：
无空则等：
有限等待：要求访问临界区的进程，保证有限时间内进入临界区，避免死等
让权等待：进程不能进入临界区时，应立即释放处理机，避免忙等
6、信号量机制：即利用PV操作来对信号量进行处理。
　　信号量（semaphore）的数据结构为一个值和一个指针，指针指向等待该信号量的下一个进程。信号量的值与相应资源的使用情况有关。
当它的值大于0时，表示当前可用资源的数量；
当它的值小于0时，其绝对值表示等待使用该资源的进程个数。
注意，信号量的值仅能由PV操作来改变。
　　一般来说，信号量S &= 0时，S表示可用资源的数量。执行一次P操作意味着请求分配一个单位资源，因此S的值减1；当S & 0时，表示已经没有可用资源，请求者必须等待别的进程释放该类资源，它才能运行下去。而执行一个V操作意味着释放一个单位资源，因此S的值加1；若S &= 0，表示有某些进程正在等待该资源，因此要唤醒一个等待状态的进程，使之运行下去。
7、进程调度：如何分配CPU。
调度方法分为可剥夺和不可剥夺两种。即当有更高优先级的进程到来时，是否可以将正在运行进程的CPU分配给高优先级的进程，可以则为可剥夺，否则为不可剥夺的。
&&&&&& 在某些操作系统中，一个作业从提交到完成需要经历高、中、低三级调度。
高级调度：又称长调度或作业调度。它决定处于输入池中的哪个后备作业可以调入主系统做好运行的准备，成为一个或一组就绪进程。系统中一个作业只需经过一次高级调度。
中级调度：又称短程调度或对换调度。它决定处于交换区中的就绪进程哪个可以调入内存，以便直接参与对CPU的竞争。在内存资源紧张时，为了将进程调入内存，必须将内存中处于阻塞状态的进程调出交换区，以便为调入进程腾出空间。
低级调度：又称短程调度或进程调度。它决定处于内存中的就绪进程中的哪个可以占用CPU。最活跃、最重要的调度程序，对系统影响也是最大的。
常见的进程调度算法：先来先服务（FCFS）、短作业优先、时间片轮转（固定时间片、可变时间片）、优先级调度（静态优先级、动态优先级）、多级反馈调度（时间片轮转+优先级调度）。
8、死锁：两个以上的进程互相要求对方已经占有的资源导致无法继续运行下去的现象
产生死锁的原因主要是：
　　&&&&&& （1） 因为系统资源不足。
　　&&&&&& （2） 进程运行推进的顺序不合适。
　　&&&&&& （3） 资源分配不当等。
　　如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。
产生死锁的四个必要条件：互斥条件、请求与保持条件、不剥夺条件、循环等待条件。
　　（1） 互斥条件：一个资源每次只能被一个进程使用。
　　（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
　　（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
　　（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
　　这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
解决死锁的4种处理策略：鸵鸟策略（即不理睬策略）、预防策略、避免策略、检测与解除策略。
死锁预防：预先静态分配法（破坏不可剥夺条件）、资源有序分配法（将资源分类按顺序排列，保证不形成环路）。
死锁避免：银行家算法（对每个资源请求进行检测，确保安全。需要很大的系统开销）。
死锁解除：资源剥夺法、撤销进程法。
9、线程与进程
进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动，是系统进行资源分配和调度的一个独立单位。
线程是进程的一个实体，是CPU调度和分派的基本单位，它是比进程更小的能独立运行的基本单位。线程自己基本上不拥有系统资源，只拥有一点在运行中必不可少的资源(如程序计数器，一组寄存器和栈)，但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。也有就绪、运行、阻塞三态。
一个线程可以创建和撤销另一个线程;同一个进程中的多个线程之间可以并发执行.
相对进程而言，线程是一个更加接近于执行体的概念，它可以与同进程中的其他线程共享数据，但拥有自己的栈空间，拥有独立的执行序列。
1) 简而言之,一个程序至少有一个进程,一个进程至少有一个线程.
2) 线程的划分尺度小于进程，使得多线程程序的并发性高。
3) 另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。
4) 线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。
5) 从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。
线程执行开销小，但不利于资源的管理和保护；而进程正相反。同时，线程适合于在SMP机器上运行，而进程则可以跨机器迁移。
5、存储管理
地址重定位：指将逻辑地址变换成物理地址的过程。分为静态重定位和动态重定位。
存储管理方案：分区存储管理（固定分区、可变分区、可重定位分区）、分页存储管理（将一个进程的地址空间划分为若干个大小相等的区域，成为页，相应地，将主存空间划分成与页相同大小的若干个物理块，称为块。至少需要两次访问主存）、分段存储管理、段页式存储管理（地址结构：段号+段内页号+页内地址）、虚拟存储管理。
&&&&&& 可变分区的请求和释放主要算法：最佳适应算法、最差适应算法、首次适应算法、循环首次适应算法。
&&&&&& 快表：在页式存储管理中将当前最活跃的少数几页的物理块号保存在高速存储器中，用以提高页式存储管理的性能。（不用两次访问主存）
&&&&&& 页面置换算法：最佳置换算法（最长时间内不再被访问的页面置换出去）、先进先出置换算法、最近最少未使用置换算法、最近未用置换算法。
6、设备管理
设备管理的目标是如何提高设备的利用率，为用户提供方便统一的界面。
设备管理采用的缓冲技术：通道技术、DMA技术、缓冲技术、Spooling技术。
磁盘调度算法：先来先服务（FCFS）、最短寻道时间（SSTF）、扫描算法（SCAN）（先由里向外，到达最外后由外向里）、单向扫描调度算法（CSCAN）（无法换向，只能由里向外）。
7、文件管理
文件的逻辑结构：有结构的记录式文件（由一个以上的记录构成。记录分为定长记录、不定长记录）、无结构的流式文件（由一串顺序的字符流构成的文件，不划分记录）。
文件的物理结构：顺序结构、链接结构、索引结构、多个物理块的索引表。
Unix的三级索引结构：
文件的存取方法：顺序存取法、随机存取法。
文件的存储空间管理：外存空闲空间管理的数据结构通常称为磁盘分配表。常用的空闲空间的管理方法：位示图（用一个bit为的0、1表示一个物理块的空闲情况）、空闲区表、空闲块链、成组链接法（每100块为一组进行记录空闲的块号和大小）。
文件链接：硬链接（两个文件目录表目指向同一个索引节点，即指不同的文件名与同一个文件实体的链接）、符号链接（在建立的新文件或目录并与原来的文件或目录的路径名进行映射）。
硬连接：原文件名和连接文件名都指向相同的物理地址。目录不能有硬连接；硬连接不能跨越文件系统（不能跨越不同的分区）文件在磁盘中只有一个拷贝，节省硬盘空间；由于删除文件要在同一个索引节点属于唯一的连接时才能成功，因此可以防止不必要的误删除。
符号连接：用ln -s命令建立文件的符号连接符号连接是linux特殊文件的一种，作为一个文件，它的数据是它所连接的文件的路径名。类似windows下的快捷方式。可以删除原有的文件而保存连接文件，没有防止误删除功能。
8、作业管理
作业状态分为4种：提交（通过输入设备送入计算机）、后备（通过Spooling系统将作业输入到计算机系统的后备存储器中，等待作业调度程序调度）、执行和完成。
常用的作业调度算法：先来先服务、短作业优先、响应比高优先、优先级调度算法、均衡调度算法。
阅读(...) 评论()}