我很少写文档,懒得写,除非项目有要求
对于文档这个东西简单谈一下
做项目之前就有文档
这个是可遇不可求的,现在做的项目很多都是临时突然说要做的,什么需求都没有,只能靠程序员自己去发现,项目经理的要求,客户的临时需求(这个比较痛苦,他们有时候根本就不知道要什么,所以必须写好文档,跟客户谈好,不然又要变的时候,你就痛苦了)
如果项目一开始就有文档,当然也可能是你自己写的,也可能是其他人写好的,有些公司有人专门负责写,需求分档,项目分析文档,项目结构文档,数据库文档等等,不过之后可能需要你写测试文档,这个就没有听说过谁帮你做了,但是更多的情况也是不用写,就几个功能,自己和测试人员测测就算了,也有可能需要写使用文档,这个看情况了
做项目之前没有文档
如果项目紧张,根本就不会写任何文档,但是当项目结束的时候,你又没有项目做,项目精灵可能就让你写写文档打发打发时间,
文档对于公司来说是很重要的,但是对于个人的话,就要看情况,如果你做了很多项目,其实什么文档也不需要,你大体上都知道这个项目就做什么用的,怎么架构的,那些代码是什么意思(你的编程习惯很好的情况下),所以很多公司都会要求程序员写文档,不然你走的时候,别的人怎么接受,让别人理解你的思想是很痛苦的,每个人的思想都是不一样的
② 程序员进行程序设计的主要文档和依据是什么
如果项目真正按照软件工程化流程走的话,主要依据是软件任务书和需求规格说明。
软件任务书规定软件的运行环境,软件需要做什么,实现哪些功能,有哪些性能要求。软件任务书中对软件功能性能的要求采用的是日常人类语言描述,如“找到员工中年龄最大的一个”。
软件需求规格说明细化软件任务书,用具体的计算机专业术语描述软件的功能需求,并详细规定输入输出,如上述任务书中找到员工年龄最大的一个可以分解为一个功能需求:
输入 全体员工的年龄,员工数目小于1000个, 输入年龄为整形数,姓名为字符类型
输出 年龄最大的员工姓名
③ 电脑中有哪些是系统文件
系统文件是指由系统软件构成的文件。大多数的系统文件只允许用户调用,但不允许用户去读,更不允许修改,有的系统文件不直接对用户开放。
电脑中系统文件有三项:
windows 或者 winnt 这个文件夹里的文件都是在安装系统时的系统文件,里边有的是必须的,有的是可能暂时用不到的。
program files 文件夹里是一些常用的你安装的应用文件,不过你安装的文件也不一定都在这个文件夹里边。
Docments and settings 是你电脑是一些用户组及其各自的设置文件,如你的管理员帐户,来宾帐户各自的设置保存。
④ 程序员如何方便的管理自己以前写的代码
一、代码的最大长度。
虽然在Java的编译器中对于代码的最大长度没有硬性的规定。但是如果代码的长度太长,超过了编译器的最当行宽,显然阅读起来比较麻烦。为此根据笔者的经验,通常情况下Java源代码的行长度不应该大于80个字符。如果超过这个长度的话,在一些开发工具和编辑器上就无法很好的显示。如需要通过滚动条来显示后面部分的代码。当其他项目成员阅读这超长的代码时,就会看得眼花缭乱。当人的温饱问题解决了之后,就需要开始注意美观方面的问题。所以程序开发人员在开发应用程序的时候,要尽量避免书写长的代码。如果代码的每行长度确实需要超过80个字符的话(最好将每行代码的长度控制在70个字符左右),那么就需要对代码进行分行。
二、在恰当的地方对代码进行分行。
笔者建议将Java源代码每行的长度控制在70个字符、最大不超过80个字符。当超过这个字符长度的时候,开发人员就需要考虑在恰当的地方对他们进行分行处理。不过这个分行也不是说开发人员想在哪里进行分行就在哪里进行分行。这个分行是有一定技巧的。虽然这些技巧大部分并不是强制性的规定,但是都是一些专家们的经验总结,可以提高代码的阅读性。为此笔者希望各位程序开发能够严格的遵守。
技巧一:高层折行优于低层折行。
这个技巧是说,在考虑对代码进行折行处理的时候,需要注意代码的层次性。如某段代码涉及到混合四则运算,而四则运算又有明显的运算顺序,此时对代码进行折行时就最好能够在四则运算的关键顺序上进行折行处理。如现在有如下的一段代码:
Mynum=mynum1*(mynum1+mynue2+mynum3-mynum4)+8*mynum5
如果要对这段代码进行折行的话,该在哪个地方加入一个折行符号呢?如果是笔者处理的话,笔者会按如下的格式对代码进行折行处理。
Mynum=mynum1*(mynum1+mynue2+mynum3-mynum4)+8*mynum5
这主要是根据四则运算的运算层次来进行折行的。显然,*符号的优先级要比+符号要高。所以在+号前面对其进行折行处理,那么就可以一目了然的反应出代码的运算层次。可以大幅度的提高代码的阅读性。所以代码折行的第一个技巧就是高层折行优于低层折行。如此的话,可以使得应用程序的结构代码更加的清晰,更容易被团队成员所理解。
技巧二:在运算符前面进行折行处理。
其实在如上的折行技巧中,还隐藏着一个规则,即在运算符之前进行折行。如上例所示,笔者就是在+号前面进行折行,而不是在+号后面进行折行处理。这主要也是考虑到代码的可读性。如上面这个例子中,如果在+号后面进行折行处理的话,则下一行就会给人一种凭空多出来的感觉,显得代码很不连贯。跟这个规则类似,如果在折行处理的时候遇到逗号时,那么最好能够在逗号后面进行折行。如在一个方法中,需要传入5个参数。此时如果代码行比较长,那么就需要在几个参数之间进行折行处理。此时最理想的折行位置,就是在某个参数的逗号后面。注意,使在逗号后面进行折行,而不是在逗号前面。因为一个参数一个逗号是匹对的。而如果一个逗号加一个参数,则让人看起来很不舒服。
技巧三:这行代码的对起方式。
当不得已对代码进行折行处理时,下一行的代码应该与其同等级的代码行左对齐。如上例所示,在+号前面将某一段四则运算公式进行折行处理的时候,其+号符号已经采取缩进处理。其缩进后的效果就是要与其同等级的代码行左对齐。如此的话,明眼人一看就知道这段代码采取过折行处理;而且跟上一行代码的层次关系。当一段代码被分割成三行甚至跟更多行数的时候,这个规则会非常的有用。如果能够严格遵守这个规则,即使将代码分割成多行,看起来也不会觉得那么混乱。反而给人一种比较有层次的感觉。
另外在采取缩进处理的时候,可以利用Tab键来提高缩进处理的效率。因为直接按空格的话,有可能空格字符数量不一致,会让人觉得层次不起,产生比较大的混乱。一般情况下,当代码行两侧距离页边的距离比较大,看其来不怎么舒服时,可以在代码行中通过插入TAB键(会在代码行中连续插入8个字符)来提高代码的阅读性,让代码的缩进实现统一。
技巧四:为变量寻找一个合适的位置。
在编写应用程序时,尽量将变量声明放置在一个代码块的开始处,也就是说{}花括号的开始位置。虽然说可以在需要使用变量的时候再对其进行声明。但是笔者不同义如此操作。因为如果在的呢感到使用变量的时候再来声明变量时,会降低代码的可读性。同理,也需要避免低层声明与高层声明重复,这样会引起代码混乱并可能引发程序功能性错误。而且这种错误在后续的排错中很难被发现。为此要在应用程序开发的时候就要尽量避免这种错误。
在声明变量的时候,有时候可能代码很简单,生命变量的行总共加起来也不会超过十个字符。此时能否把多个变量的声明写在同一行呢?从就技术上来说,这是可行的。也就是说,Java编译器允许将多个变量定义在同一行上。但是从阅读性上来说,这并不是很好的做法。笔者的建议是,即使变量定义再简单,或者变量比较多,也最好分行进行变量的声明。也就是说,一行声明一个变量。这可以提高代码的可阅读性。而且有时候往往需要对变量加一个注释说明变量的用途,如果以行定义一个变量,添加行注释也相对简单许多。
总之,以上的这些折行的规则基本上不会影响到代码的运行。但是,对于代码的维护与后续的排错、升级、二次开发等等具有不可忽视的作用。而且现在基本上应用程序开发式团队开发,故大家都遵守同样的代码编写规范是非常重要的。笔者在开发一个应用程序的时候,事先都会花一定的时间,跟项目成员强调这些折行的规则。目的只有一个,就是提高代码的可读性,便于后续代码的共享与维护。毕竟后续面对这些代码的,并不是客户,而是我们自己。我们程序员在编写代码的时候,不能够搬起石头砸自己的脚。笔者认为,现在一个合格的程序人员,不仅技术功底上要过得硬,而且还必须要遵守这些无形规则的约束。难怪现在这么多企业在挑选程序开发人员的时候,都会注明良好的编码规范。现在对于这些无形中的条条框框,项目经理已经开始重视起来。
⑤ 软件开发文档的分类
1. 《功能要求》 -- 来源于客户要求和市场调查,是软件开发中最早期的一个环节。客户提出一个模糊的功能概念,或者要求解决一个实际问题,或者参照同类软件的一个功能。有软件经验的客户还会提供比较详细的技术规范书,把他们的要求全部列表书写在文档中,必要时加以图表解说。这份文档是需求分析的基础。
2. 《投标方案》 -- 根据用户的功能要求,经过与招标方沟通和确认,技术人员开始书写《投标方案》,方案书一般包括以下几个重要的章节: 前言 -- 项目背景、公司背景和业务、技术人员结构、公司的成功案例介绍等。 需求分析 -- 项目要求、软件结构、功能列表、功能描述、注意事项等。 技术方案 -- 总体要求和指导思想、技术解决方案、软件开发平台、网络结构体系等。 项目管理 -- 描述公司的软件开发流程、工程实施服务、组织和人员分工、开发进度控制、软件质量保证、项目验收和人员培训、软件资料文档等。 技术支持 -- 公司的技术支持和服务介绍、服务宗旨和目标、服务级别和响应时间、技术服务区域、技术服务期限、授权用户联系人等。 系统报价 -- 软、硬件平台报价列表、软件开发费用、系统维护费用等。 项目进度 -- 整个项目的进度计划,包括签署合同、项目启动、需求分析、系统分析、程序开发、测试维护、系统集成、用户验收、用户培训等步骤的时间规划。
3. 《需求分析》 -- 包括产品概述、主要概念、操作流程、功能列表和解说、注意事项、系统环境等。以《功能要求》为基础,进行详细的功能分析 ( 包括客户提出的要求和根据开发经验建议的功能 ) ,列出本产品是什么,有什么特殊的概念,包括哪些功能分类,需要具备什么功能,该功能的操作如何,实现的时候该注意什么细节,客户有什么要求,系统运行环境的要求等。这里的功能描述跟以后的使用手册是一致的。
4. 《技术分析》 -- 包括技术选型、技术比较、开发人员、关键技术问题的解决、技术风险、技术升级方向、技术方案评价,竞争对手技术分析等。以《需求分析》为基础,进行详细的技术分析 ( 产品的性能和实现方法 ) ,列出本项目需要使用什么技术方案,为什么,有哪些技术问题要解决 ,估计开发期间会碰到什么困难,技术方案以后如何升级,对本项目的技术有什么评价等。
5. 《系统分析》 -- 包括功能实现、模块组成、功能流程图、函数接口、数据字典、软件开发需要考虑的各种问题等。以《需求分析》为基础,进行详细的系统分析 ( 产品的开发和实现方法 ) ,估计开发期间需要把什么问题说明白,程序员根据《系统分析》,开始在项目主管的带领下进行编码。
6. 《数据库文档》 -- 包括数据库名称、表名、字段名、字段类型、字段说明、备注、字段数值计算公式等。以《系统分析》为基础,进行详细的数据库设计。必要时可以用图表解说,特别是关系数据库。
7. 《功能函数文档》 -- 包括变量名、变量初值、功能,函数名,参数,如何调用、备注、注意事项等。以《系统分析》为基础,进行详细的说明,列出哪个功能涉及多少个函数,以便以后程序员修改、接手和扩展。
8. 《界面文档》 -- 包括软件外观、界面素材、编辑工具、文件名、菜单、按钮和其它界面部件的要求,这里与软件完成后的运行界面是一致的。
9. 《编译手册》 -- 包括服务器编译环境、操作系统、编译工具、 GNU 的 C++ 编译器版本信息、目录说明、程序生成、源程序文件列表、 Makefile 配置及其相关程序的对应关系列表。客户端的编译过程、编译结果、编译示例、编译环境、操作系统、编译工具、源文件列表和制作安装程序的过程。
10. 《 QA 文档》 -- 包括产品简介、产品原理、产品功能列表、功能描述、功能流程、执行结果、数据库结构、测试要求等,提供给软件测试人员使用。
11. 《项目总结》 -- 包括项目简介、项目参与人员和开发时间、项目风险管理过程、项目功能列表、项目结构特点、技术特点、对项目的升级建议、对以后的项目的建议、人员素质情况等。 1. 《产品简介》 -- 包括公司背景、产品概念、适用范围、产品功能、功能特点、运行要求和公司联系地址。
2. 《产品演示》 -- 包括公司简介、产品背景、产品描述、产品特点、产品作用、适用范围、使用分析、功能模块、解决问题、合作伙伴、成功案例等。一般用 Power point 或者 VCD 录制软件实现。
3. 《疑问解答》 -- 列出用户关心的问题和处理方法。用于解答软件的操作功能和解决用户的疑难问题。
4. 《功能介绍》 -- 以《需求分析》为书写基础,包括软件介绍、软件结构、功能列表、功能描述和公司联系地址。
5. 《技术白皮书》 -- 以《技术分析》为书写基础,包括功能实现、技术选型、关键技术问题的解决、技术方案特点、技术升级方向等。
6. 《评测报告》 -- 第三方权威评测报告。包括评测目的、评测范围、评测环境、评测内容、实测数据、性能表现、结果分析和评测总结等。
7. 《安装手册》 -- 包括系统环境、运行平台、产品安装过程、初始环境设置、安装记录等。
8. 《使用手册》 -- 包括产品简介、功能列表、功能描述和解释、功能操作、客户服务和联系方式等。
9. 《维护手册》 -- 包括产品简介、系统须知、初始环境设置、系统配置、数据管理和备份、技术问题解答和联系方式等。
10. 《用户报告》 -- 包括产品简介、购买时间、使用目的、使用时间、使用地点、实施过程、出现问题和解决、产品总结和建议等。
11. 《销售培训》 -- 包括项目简介、产品功能、产品特点、商业优势、系统运行环境、适用范围、目标客户等。 第一、需求分析文档
用户需求分析文档是指在和客户进行沟通时,把用户所要求的信息记录下来,根据用户的要求进行需求分析,规划出我们要开发的软件所要实现哪些功能。
第二、概要设计文档
概要设计:顾名思义,就是对我们所要开发的软件进行一个整体的概括,把这个软件所包含的功能模块作一个设计,以后我们在开发的时候就有目标,有方向了。
第三、系统设计文档
系统设计,就是对概要的一个详细的实施,就是分析我们所要开发软件各大功能模块中所包含的小模块,把这些小模块都一一列举出来,然后再对软件开发人员进行有条理的进行开发任务的分配。
第四、详细设计文档
详细设计文档,主要是把我们每个小模块,小功能的业务逻辑处理用文字的方式表达出来,让程序员在编码的时候有一个依据和参照;同时,在进行详细文档设计的时候,有的软件公司也会根据不同的项目作出相应的《软件开发代码规范》性文档。以保障我们所做工作的统一性。
第五、软件测试文档
当我们参照软件详细设计文档编码完成后,接着就会根据我们所实现的功能,进行软件测试文档的编写;大多测试文档有两类,一类是软件单体测试文档,一类是软件结合测试文档;顾名思义,单体测试:就是对软件中每个小的方法,一个独立的方法进行测试的文档;结合测试:就是把多个功能模块组合到一起进行测试,主要是为了检测每个功能模块之前的交互性和功能的结合实现性。
第六、软件完成后的总结汇报型文档
不管所开发软件的规模大小,在一个软件开发结束后,我们都会把开发过中的问题和项目开发总结一起记录下来,以防以后在开发过程中再有类似问题出现,提高我们的开发效率。
根据软件开发公司的规模、标准和客户的需求不同,开发文档的种类和数量也不同,我在这里和大家讨论的软件开发相关文档都是最基础的;在软件行业有一句话:一个软件能否顺利的完成并且功能是否完善,重要是看这个软件有多少文档,软件开发文档是一个软件的支柱,如果你的开发文档漏洞百出,那么你所开发出来的软件也不可能会好;开发文档的好坏可以直接影响到所开发出来软件的成功与否。
⑥ 程序员必备知识(操作系统5-文件系统)
本篇与之前的第三篇的内存管理知识点有相似的地方
对于运行的进程来说,内存就像一个纸箱子, 仅仅是一个暂存数据的地方, 而且空间有限。如果我们想要进程结束之后,数据依然能够保存下来,就不能只保存在内存里,而是应该保存在 外部存储 中。就像图书馆这种地方,不仅空间大,而且能够永久保存。
我们最常用的外部存储就是 硬盘 ,数据是以文件的形式保存在硬盘上的。为了管理这些文件,我们在规划文件系统的时候,需要考虑到以下几点。
第一点,文件系统要有严格的组织形式,使得文件能够 以块为单位进行存储 。这就像图书馆里,我们会给设置一排排书架,然后再把书架分成一个个小格子,有的项目存放的资料非常多,一个格子放不下,就需要多个格子来进行存放。我们把这个区域称为存放原始资料的 仓库区 。
第二点,文件系统中也要有 索引区 ,用来方便查找一个文件分成的多个块都存放在了什么位置。这就好比,图书馆的书太多了,为了方便查找,我们需要专门设置一排书架,这里面会写清楚整个档案库有哪些资料,资料在哪个架子的哪个格子上。这样找资料的时候就不用跑遍整个档案库,在这个书架上找到后,直奔目标书架就可以了。
第三点,如果文件系统中有的文件是热点文件,近期经常被读取和写入,文件系统应该有 缓存层 。这就相当于图书馆里面的热门图书区,这里面的书都是畅销书或者是常常被借还的图书。因为借还的次数比较多,那就没必要每次有人还了之后,还放回遥远的货架,我们可以专门开辟一个区域, 放置这些借还频次高的图书。这样借还的效率就会提高。
第四点,文件应该用 文件夹 的形式组织起来,方便管理和查询。这就像在图书馆里面,你可以给这些资料分门别类,比如分成计算机类.文学类.历史类等等。这样你也容易管理,项目组借阅的时候只要在某个类别中去找就可以了。
在文件系统中,每个文件都有一个名字,这样我们访问一个文件,希望通过它的名字就可以找到。文件名就是一个普通的文本。 当然文件名会经常冲突,不同用户取相同的名字的情况还是会经常出现的。
要想把很多的文件有序地组织起来,我们就需要把它们成为 目录 或者文件夹。这样,一个文件夹里可以包含文件夹,也可以包含文件,这样就形成了一种 树形结构 。而我们可以将不同的用户放在不同的用户目录下,就可以一定程度上避免了命名的冲突问题。
第五点,Linux 内核要在自己的内存里面维护一套数据结构,来保存哪些文件被哪些进程打开和使用 。这就好比,图书馆里会有个图书管理系统,记录哪些书被借阅了,被谁借阅了,借阅了多久,什么时候归还。
文件系统是操作系统中负责管理持久数据的子系统,说简单点,就是负责把用户的文件存到磁盘硬件中,因为即使计算机断电了,磁盘里的数据并不会丢失,所以可以持久化的保存文件。
文件系统的基本数据单位是 文件 ,它的目的是对磁盘上的文件进行组织管理,那组织的方式不同,就会形成不同的文件系统。
Linux最经典的一句话是:“一切皆文件”,不仅普通的文件和目录,就连块设备、管道、socket 等,也都是统一交给文件系统管理的。
Linux文件系统会为每个文件分配两个数据结构: 索引节点(index node) 和 目录项(directory entry) ,它们主要用来记录文件的元信息和目录层次结构。
●索引节点,也就是inode, 用来记录文件的元信息,比如inode编号、文件大小访问权限、创建时间、修改时间、 数据在磁盘的位置 等等。 索引节点是文件的唯一标识 ,它们之间一一对应, 也同样都会被 存储在硬盘 中,所以索引节点同样占用磁盘空间。
●目录项,也就是dentry, 用来记录文件的名字、索引节点指针以及与其他目录项的层级关联关系。多个目录项关联起来,就会形成 目录结构 ,但它与索引节点不同的是,目录项是由内核维护的一个数据结构,不存放于磁盘,而是 缓存在内存 。
由于索引节点唯一标识一个文件,而目录项记录着文件的名,所以目录项和索引节点的关系是多对一,也就是说,一个文件可以有多个别字。比如,硬链接的实现就是多个目录项中的索引节点指向同一个文件。
注意,目录也是文件,也是用索引节点唯一标识,和普通文件不同的是,普通文件在磁盘里面保存的是文件数据,而目录文件在磁盘里面保存子目录或文件。
(PS:目录项和目录不是一个东西!你也不是一个东西(^_=), 虽然名字很相近,但目录是个文件。持久化存储在磁盘,而目录项是内核一个数据结构,缓存在内存。
如果查询目录频繁从磁盘读,效率会很低,所以内核会把已经读过的目录用目录项这个数据结构缓存在内存,下次再次读到相同的目录时,只需从内存读就可以,大大提高了 文件系统的效率。
目录项这个数据结构不只是表示目录,也是可以表示文件的。)
磁盘读写的最小单位是 扇区 ,扇区的大小只有512B大小,很明显,如果每次读写都以这么小为单位,那这读写的效率会非常低。
所以,文件系统把多个扇区组成了一个 逻辑块 ,每次读写的最小单位就是逻辑块(数据块) , Linux中的逻辑块大小为4KB,也就是一次性读写 8个扇区,这将大大提高了磁盘的读写的效率。
以上就是索引节点、目录项以及文件数据的关系,下面这个图就很好的展示了它们之间的关系:
索引节点是存储在硬盘上的数据,那么为了加速文件的访问,通常会把索引节点加载到内存中。
另外,磁盘进行格式化的时候,会被分成三个存储区域,分别是超级块、索引节点区和数据块区。
●超级块,用来存储文件系统的详细信息,比如块个数、块大小、空闲块等等。
●索引节点区,用来存储索引节点;
●数据块区,用来存储文件或目录数据;
我们不可能把超级块和索引节点区全部加载到内存,这样内存肯定撑不住,所以只有当需要使用的时候,才将其加载进内存,它们加载进内存的时机是不同的.
●超级块:当文件系统挂载时进入内存;
●索引节点区:当文件被访问时进入内存;
文件系统的种类众多,而操作系统希望 对用户提供一个统一的接口 ,于是在用户层与文件系统层引入了中间层,这个中间层就称为 虚拟文件系统(Virtual File System, VFS) 。
VFS定义了一组所有文件系统都支持的数据结构和标准接口,这样程序员不需要了解文件系统的工作原理,只需要了解VFS提供的统一接口即可。
在Linux文件系统中,用户空间、系统调用、虚拟机文件系统、缓存、文件系统以及存储之间的关系如下图:
Linux支持的文件系统也不少,根据存储位置的不同,可以把文件系统分为三类:
●磁盘的文件系统,它是直接把数据存储在磁盘中,比如Ext 2/3/4. XFS 等都是这类文件系统。
●内存的文件系统,这类文件系统的数据不是存储在硬盘的,而是占用内存空间,我们经常用到的/proc 和/sys文件系统都属于这一类,读写这类文件,实际上是读写内核中相关的数据。
●网络的文件系统,用来访问其他计算机主机数据的文件系统,比如NFS. SMB等等。
文件系统首先要先挂载到某个目录才可以正常使用,比如Linux系统在启动时,会把文件系统挂载到根目录。
在操作系统的辅助之下,磁盘中的数据在计算机中都会呈现为易读的形式,并且我们不需要关心数据到底是如何存放在磁盘中,存放在磁盘的哪个地方等等问题,这些全部都是由操作系统完成的。
那么,文件数据在磁盘中究竟是怎么样的呢?我们来一探究竟!
磁盘中的存储单元会被划分为一个个的“ 块 ”,也被称为 扇区 ,扇区的大小一般都为512byte.这说明即使一块数据不足512byte,那么它也要占用512byte的磁盘空间。
而几乎所有的文件系统都会把文件分割成固定大小的块来存储,通常一个块的大小为4K。如果磁盘中的扇区为512byte,而文件系统的块大小为4K,那么文件系统的存储单元就为8个扇区。这也是前面提到的一个问题,文件大小和占用空间之间有什么区别?文件大小是文件实际的大小,而占用空间则是因为即使它的实际大小没有达到那么大,但是这部分空间实际也被占用,其他文件数据无法使用这部分的空间。所以我们 写入1byte的数据到文本中,但是它占用的空间也会是4K。
这里要注意在Windows下的NTFS文件系统中,如果一开始文件数据小于 1K,那么则不会分配磁盘块来存储,而是存在一个文件表中。但是一旦文件数据大于1K,那么不管以后文件的大小,都会分配以4K为单位的磁盘空间来存储。
与内存管理一样,为了方便对磁盘的管理,文件的逻辑地址也被分为一个个的文件块。于是文件的逻辑地址就是(逻辑块号,块内地址)。用户通过逻辑地址来操作文件,操作系统负责完成逻辑地址与物理地址的映射。
不同的文件系统为文件分配磁盘空间会有不同的方式,这些方式各自都有优缺点。
连续分配要求每个文件在磁盘上有一组连续的块,该分配方式较为简单。
通过上图可以看到,文件的逻辑块号的顺序是与物理块号相同的,这样就可以实现随机存取了,只要知道了第一个逻辑块的物理地址, 那么就可以快速访问到其他逻辑块的物理地址。那么操作系统如何完成逻辑块与物理块之间的映射呢?实际上,文件都是存放在目录下的,而目录是一种有结构文件, 所以在文件目录的记录中会存放目录下所有文件的信息,每一个文件或者目录都是一个记录。 而这些信息就包括文件的起始块号和占有块号的数量。
那么操作系统如何完成逻辑块与物理块之间的映射呢? (逻辑块号, 块内地址) -> (物理块号, 块内地址),只需要知道逻辑块号对应的物理块号即可,块内地址不变。
用户访问一个文件的内容,操作系统通过文件的标识符找到目录项FCB, 物理块号=起始块号+逻辑块号。 当然,还需要检查逻辑块号是否合法,是否超过长度等。因为可以根据逻辑块号直接算出物理块号,所以连续分配支持 顺序访问和随机访问 。
因为读/写文件是需要移动磁头的,如果访问两个相隔很远的磁盘块,移动磁头的时间就会变长。使用连续分配来作为文件的分配方式,会使文件的磁盘块相邻,所以文件的读/写速度最快。
连续空间存放的方式虽然读写效率高,但是有 磁盘空间碎片 和 文件长度不易扩展 的缺陷。
如下图,如果文件B被删除,磁盘上就留下一块空缺,这时,如果新来的文件小于其中的一个空缺,我们就可以将其放在相应空缺里。但如果该文件的大小大于所
有的空缺,但却小于空缺大小之和,则虽然磁盘上有足够的空缺,但该文件还是不能存放。当然了,我们可以通过将现有文件进行挪动来腾出空间以容纳新的文件,但是这个在磁盘挪动文件是非常耗时,所以这种方式不太现实。
另外一个缺陷是文件长度扩展不方便,例如上图中的文件A要想扩大一下,需要更多的磁盘空间,唯一的办法就只能是挪动的方式,前面也说了,这种方式效率是非常低的。
那么有没有更好的方式来解决上面的问题呢?答案当然有,既然连续空间存放的方式不太行,那么我们就改变存放的方式,使用非连续空间存放方式来解决这些缺陷。
非连续空间存放方式分为 链表方式 和 索引方式 。
链式分配采取离散分配的方式,可以为文件分配离散的磁盘块。它有两种分配方式:显示链接和隐式链接。
隐式链接是只目录项中只会记录文件所占磁盘块中的第一块的地址和最后一块磁盘块的地址, 然后通过在每一个磁盘块中存放一个指向下一 磁盘块的指针, 从而可以根据指针找到下一块磁盘块。如果需要分配新的磁盘块,则使用最后一块磁盘块中的指针指向新的磁盘块,然后修改新的磁盘块为最后的磁盘块。
我们来思考一个问题, 采用隐式链接如何将实现逻辑块号转换为物理块号呢?
用户给出需要访问的逻辑块号i,操作系统需要找到所需访问文件的目录项FCB.从目录项中可以知道文件的起始块号,然后将逻辑块号0的数据读入内存,由此知道1号逻辑块的物理块号,然后再读入1号逻辑块的数据进内存,此次类推,最终可以找到用户所需访问的逻辑块号i。访问逻辑块号i,总共需要i+ 1次磁盘1/0操作。
得出结论: 隐式链接分配只能顺序访问,不支持随机访问,查找效率低 。
我们来思考另外一个问题,采用隐式链接是否方便文件拓展?
我们知道目录项中存有结束块号的物理地址,所以我们如果要拓展文件,只需要将新分配的磁盘块挂载到结束块号的后面即可,修改结束块号的指针指向新分配的磁盘块,然后修改目录项。
得出结论: 隐式链接分配很方便文件拓展。所有空闲磁盘块都可以被利用到,无碎片问题,存储利用率高。
显示链接是把用于链接各个物理块的指针显式地存放在一张表中,该表称为文件分配表(FAT, File Allocation Table)。
由于查找记录的过程是在内存中进行的,因而不仅显着地 提高了检索速度 ,而且 大大减少了访问磁盘的次数 。但也正是整个表都存放在内存中的关系,它的主要的缺点是 不适 用于大磁盘 。
比如,对于200GB的磁盘和1KB大小的块,这张表需要有2亿项,每一项对应于这2亿个磁盘块中的一个块,每项如果需要4个字节,那这张表要占用800MB内存,很显然FAT方案对于大磁盘而言不太合适。
一直都在,加油!(*゜Д゜)σ凸←自爆按钮
链表的方式解决了连续分配的磁盘碎片和文件动态打展的问题,但是不能有效支持直接访问(FAT除外) ,索引的方式可以解决这个问题。
索引的实现是为每个文件创建一个 索引数据块 ,里面存放的 是指向文件数据块的指针列表 ,说白了就像书的目录一样,要找哪个章节的内容,看目录查就可以。
另外, 文件头需要包含指向索引数据块的指针 ,这样就可以通过文件头知道索引数据块的位置,再通过索弓|数据块里的索引信息找到对应的数据块。
创建文件时,索引块的所有指针都设为空。当首次写入第i块时,先从空闲空间中取得一个块, 再将其地址写到索引块的第i个条目。
索引的方式优点在于:
●文件的创建、增大、缩小很方便;
●不会有碎片的问题;
●支持顺序读写和随机读写;
由于索引数据也是存放在磁盘块的,如果文件很小,明明只需一块就可以存放的下,但还是需要额外分配一块来存放索引数据,所以缺陷之一就是存储索引带来的开销。
如果文件很大,大到一个索引数据块放不下索引信息,这时又要如何处理大文件的存放呢?我们可以通过组合的方式,来处理大文件的存储。
先来看看 链表+索引 的组合,这种组合称为 链式索引块 ,它的实现方式是在 索引数据块留出一个存放下一个索引数据块的指针 ,于是当一个索引数据块的索引信息用完了,就可以通过指针的方式,找到下一个索引数据块的信息。那这种方式也会出现前面提到的链表方式的问题,万一某个指针损坏了,后面的数据也就会无法读取了。
还有另外一种组合方式是 索引+索引 的方式,这种组合称为多级索引块,实现方式是通过一个索引块来存放多个索引数据块,一层套一层索引, 像极了俄罗斯套娃是吧๑乛◡乛๑
前面说到的文件的存储是针对已经被占用的数据块组织和管理,接下来的问题是,如果我要保存一个数据块, 我应该放在硬盘上的哪个位置呢?难道需要将所有的块扫描一遍,找个空的地方随便放吗?
那这种方式效率就太低了,所以针对磁盘的空闲空间也是要引入管理的机制,接下来介绍几种常见的方法:
●空闲表法
●空闲链表法
●位图法
空闲表法
空闲表法就是为所有空闲空间建立一张表,表内容包括空闲区的第一个块号和该空闲区的块个数,注意,这个方式是连续分配的。如下图:
当请求分配磁盘空间时,系统依次扫描空闲表里的内容,直到找到一个合适的空闲区域为止。当用户撤销一个文件时,系统回收文件空间。这时,也需顺序扫描空闲表,寻找一个空闲表条目并将释放空间的第一个物理块号及它占用的块数填到这个条目中。
这种方法仅当有少量的空闲区时才有较好的效果。因为,如果存储空间中有着大量的小的空闲区,则空闲表变得很大,这样查询效率会很低。另外,这种分配技术适用于建立连续文件。
空闲链表法
我们也可以使用链表的方式来管理空闲空间,每一个空闲块里有一个指针指向下一个空闲块,这样也能很方便的找到空闲块并管理起来。如下图:
当创建文件需要一块或几块时,就从链头上依次取下一块或几块。反之,当回收空间时,把这些空闲块依次接到链头上。
这种技术只要在主存中保存一个指针, 令它指向第一个空闲块。其特点是简单,但不能随机访问,工作效率低,因为每当在链上增加或移动空闲块时需要做很多1/0操作,同时数据块的指针消耗了一定的存储空间。
空闲表法和空闲链表法都不适合用于大型文件系统,因为这会使空闲表或空闲链表太大。
位图法
位图是利用二进制的一位来表示磁盘中一个盘块的使用情况,磁盘上所有的盘块都有一个二进制位与之对应。
当值为0时,表示对应的盘块空闲,值为1时,表示对应的盘块已分配。它形式如下:
在Linux文件系统就采用了位图的方式来管理空闲空间,不仅用于数据空闲块的管理,还用于inode空闲块的管理,因为inode也是存储在磁盘的,自然也要有对其管理。
前面提到Linux是用位图的方式管理空闲空间,用户在创建一个新文件时, Linux 内核会通过inode的位图找到空闲可用的inode,并进行分配。要存储数据时,会通过块的位图找到空闲的块,并分配,但仔细计算一下还是有问题的。
数据块的位图是放在磁盘块里的,假设是放在一个块里,一个块4K,每位表示一个数据块,共可以表示4 * 1024 * 8 = 2^15个空闲块,由于1个数据块是4K大小,那么最大可以表示的空间为2^15 * 4 * 1024 = 2^27个byte,也就是128M。
也就是说按照上面的结构,如果采用(一个块的位图+ 一系列的块),外加一(个块的inode的位图+一系列的inode)的结构能表示的最大空间也就128M,
这太少了,现在很多文件都比这个大。
在Linux文件系统,把这个结构称为一个 块组 ,那么有N多的块组,就能够表示N大的文件。
最终,整个文件系统格式就是下面这个样子。
最前面的第一个块是引导块,在系统启动时用于启用引导,接着后面就是一个一个连续的块组了,块组的内容如下:
● 超级块 ,包含的是文件系统的重要信息,比如inode总个数、块总个数、每个块组的inode个数、每个块组的块个数等等。
● 块组描述符 ,包含文件系统中各个块组的状态,比如块组中空闲块和inode的数目等,每个块组都包含了文件系统中“所有块组的组描述符信息”。
● 数据位图和inode位图 ,用于表示对应的数据块或inode是空闲的,还是被使用中。
● inode 列表 ,包含了块组中所有的inode, inode 用于保存文件系统中与各个文件和目录相关的所有元数据。
● 数据块 ,包含文件的有用数据。
你可以会发现每个块组里有很多重复的信息,比如 超级块和块组描述符表,这两个都是全局信息,而且非常的重要 ,这么做是有两个原因:
●如果系统崩溃破坏了超级块或块组描述符,有关文件系统结构和内容的所有信息都会丢失。如果有冗余的副本,该信息是可能恢复的。
●通过使文件和管理数据尽可能接近,减少了磁头寻道和旋转,这可以提高文件系统的性能。
不过,Ext2 的后续版本采用了稀疏技术。该做法是,超级块和块组描述符表不再存储到文件系统的每个块组中,而是只写入到块组0、块组1和其他ID可以表示为3、5、7的幂的块组中。
在前面,我们知道了一个普通文件是如何存储的,但还有一个特殊的文件,经常用到的目录,它是如何保存的呢?
基于Linux 一切切皆文件的设计思想,目录其实也是个文件,你甚至可以通过vim打开它,它也有inode, inode 里面也是指向一些块。
和普通文件不同的是, 普通文件的块里面保存的是文件数据,而目录文件的块里面保存的是目录里面一项一项的文件信息 。
在目录文件的块中,最简单的保存格式就是 列表 ,就是一项一项地将目录下的文件信息(如文件名、文件inode.文件类型等)列在表里。
列表中每一项就代表该目录下的文件的文件名和对应的inode,通过这个inode,就可以找到真正的文件。
通常,第一项是“则”,表示当前目录,第二项是.,表示上一级目录, 接下来就是一项一项的文件名和inode。
如果一个目录有超级多的文件,我们要想在这个目录下找文件,按照列表一项一项的找,效率就不高了。
于是,保存目录的格式改成 哈希表 ,对文件名进行哈希计算,把哈希值保存起来,如果我们要查找一个目录下面的文件名,可以通过名称取哈希。如果哈希能够匹配上,就说明这个文件的信息在相应的块里面。
Linux系统的ext文件系统就是采用了哈希表,来保存目录的内容,这种方法的优点是查找非常迅速,插入和删除也较简单,不过需要一些预备措施来避免哈希冲突。
目录查询是通过在磁盘上反复搜索完成,需要不断地进行/0操作,开销较大。所以,为了减少/0操作,把当前使用的文件目录缓存在内存,以后要使用该文件时只要在内存中操作,从而降低了磁盘操作次数,提高了文件系统的访问速度。
感谢您的阅读,希望您能摄取到知识!加油!冲冲冲!(发现光,追随光,成为光,散发光!)我是程序员耶耶!有缘再见。<-biubiu-⊂(`ω´∩)
⑦ 为什么程序员都有js 和css文件夹
这个就好像一个分类,为了代码方便管理,你不要文件夹把所有代码放在一起也是可以的,但是这样不方便代码管理。我们不仅仅是要开发还有后期维护,这样将js统一放到js文件夹里面就可以快速的从js文件夹里面找到对应的js文件来进行修改。
⑧ 电脑的系统文件有哪些
方法/步骤
C盘windows可以删除的文件
Windows里面的Temp(系统临时文件);SoftwareDistribution内部的download;Prefetch等这些文件夹里面的所有文件都可以删除
C盘DocumentsandSettings可以删除的文件
DocumentsandSettings里用户内部的:Recent;Cookies;LocalSettings下的History、Temp、TemporaryInternetFiles等文件夹里面的文件都可以删除,不会影响系统正常运行的
如果你有很多东西需要存放到电脑上,建议你最好放在E盘或者F盘,这样既不会影响C盘的容量,也不会影响电脑的运行速度及安全性。