展开全部
1、绝对路径
从根目录32313133353236313431303231363533e4b893e5b19e31333365646263开始，依次将各级子目录的名字组合起来，形成的路径就称为某个文件的绝对路径。例如，根目录(/)下有目录usr，usr目录下有子目录bin，bin目录下有文件chsh，则chsh文件的绝对路径就是：/usr/bin/chsh
2、相对路径
相对当前所在路径的位置，例如当前所在的位置为/usr，也就是在根目录的usr子目录下，则chsh文件相对当前位置的路径为：bin/chs
一·在windows读取文件可以用\，但在字符串里面\被作为转义字符使用，那么在描述路径时有两种方式：
'c:\\a.txt'，转义的方式
r'c:\a.txt'，声明字符串不需要转义
这样就实现了用\来访问路径。
二·python提供了兼容处理，让Linux风格路径在windows下可用，于是很多时候大家都会选Linux风格。这样简单的脚本可以在两个平台下都能运行。
python对windows路径处理有一个库叫ntpath。
windows用\分割路径是因为当年DOS时代将/作为参数引导使用了，懒惰的某人不愿花时间处理相关解析，于是为了赶工粗暴的使用了\替代。
三·不能直接使用C://这样的绝对路径，不符合网络地址规范，案例如下：
var img = new Image();
img.src = "C://Users//Administrator//Desktop//shilian//_ditu.png";  // Refused to load the image 'c://Users//Administrator//Desktop//shilian//_ditu.png' because it violates the following Content Security Policy directive: "img-src * data: blob:".
四·相对路径down下来，也是基于http的访问协议，或者本地的file://协议，“C://"前面加上”file://“

前言
在知乎上看到很多童鞋在学Java的时候，因为安装jdk时没有正确的配置，会遇到很多问题。所以决定今天写一下jdk在Windows、Mac、Linux下都怎么安装。
下载JDK
“巧妇难为无米之炊”，所以首先我们要去Oracle官网上下载jdk，Java8下载，根据笔记本的操作系统选择jdk进行下载。

图中的就是三个系统分别对应的JDK，可以下拉选择其他的版本。不过值得一提的是，下载jdk的话需要注册oracle账号，还是挺麻烦的。所以我将三个系统的JDK都放到了百度云盘中。

上图就是云盘中的jdk文件。
Windows
从官网来看，oracle提供的windows版本的jdk是exe安装包。双击就可以安装。其实这里真的是不建议下载exe进行安装。曾经在知乎上遇到过一个想玩我的世界的人，因为不懂Java就随便从网上下载了jdk进行安装，安装之后不仅我的世界玩不了，想安装java8都报错，后来我在我之前的笔记本上找到了免安装版，并远程帮他安上了Java8，我的世界才运行了起来。
所以，我建议下载免安装版进行安装，我在云盘里分享的就是zip免安装版，这里就讲一下免安装版的Java环境配置。
解压zip
将下载的zip包进行解压，并进入解压后的jdk目录，并复制当前目录的路径。
配置jdk
找到此电脑 -> 右键，选择属性，进入如下页面

点击高级系统设置，进入系统属性页面

点击高级，点击环境变量，进入页面。
点击新建，变量名为JAVA_HOME，变量值为刚开始拷贝的jdk目录。
选中Path，点击编辑，添加一行 %JAVA_HOME%/bin
验证
在cmd命令行里面，输入java -version，如果正常输出版本信息，则安装成功。
Linux
Linux下尤其简单，这里使用jdk-8u201-linux-x64.tar.gz为例。
下载jdk的tar.gz文件，使用以下命令解压
tar zxvf jdk-8u201-linux-x64.tar.gz
进入解压后的目录，执行pwd，复制当前的jdk目录路径。
修改环境变量
如果你有root权限，就修改全局环境变量文件/etc/profile，在文件结尾添加如下两行：
# 这里的/data需要替换成你的目录
export JAVA_HOME=/data/jdk1.8.0_201
export JAVA_HOME=$PATH:$JAVA_HOME/bin
执行以下命令使更改生效：
source /ect/profile
如果你是普通用户权限，就修改此用户的环境变量文件。
执行以下命令：
vi ~/.bash_profile
然后将上面的两行代码添加到此文件的结尾即可。
执行以下命令使更改生效：
source ~./bash_profile
验证
执行java -version查看是否正确输出Java版本信息。
Mac
Mac的jdk安装是真的简单到不能再简单了。
下载jdk-8u202-macosx-x64.dmg，双击出现以下界面

点击中间黄色部分。

点击继续，跟着提示一直点击继续，直到安装成功。
java -version验证一波。
庆祝一波 - Hello World
编辑HelloWorld.java文件

javac将java文件编译成class文件，java运行。
结语
上面就是Windows、Linux、Mac系统安装JDK的方法。至于JDK的下载，大家可以去官网下载。

希望这篇文章能让大家迈进Java的大门，也祝大家以后在Java这条路上越走越远。

之前有两篇文章整理过linux虚拟文件系统的结构，和linux文件读写的流程。其中一些由具体文件系统类型来实现的地方并没有深入叙述，只是说这是由具体的文件系统来实现的。比如，读写文件的时候，文件的读写位置怎么对应到实际的磁盘块呢？这是由具体的文件系统来实现的；再比如，寻找一个文件路径的时候，怎么知道XXX目录下是否有YYY文件存在呢？这也是由具体的文件系统来实现的。
前些天同事问起linux下inode的含义，我也就此整理一下自己的思路，看看具体的文件系统大致需要实现什么样的功能，并且可以怎样去实现。

inode
先从inode说起。文件系统中的文件形成了一个树型结构，其中的每一个结点就是一个文件（目录也是文件），对应一个inode。inode的具体结构因文件系统类型的不同而异，但是大体上应该包含如下信息：文件所有者（包括uid、gid）、权限位、文件大小、时间（创建时间、修改时间等）、文件内容。其中最值得一说的是文件内容。
文件有目录和普通文件之分，这两者的内容有着不同的含义，其内容的组织也可能有着不同的结构。

对于普通文件来说，其内容就是用户能够看到的文件内容。当用户程序通过系统调用读写文件时，需要通过某种索引结构来知道文件中某个offset的数据应该在哪个磁盘块上，然后转换成对该块的读写请求。当文件的内容很小时，文件内容的索引信息可以完全存放在inode结点中；如果文件很大，索引也会很大，inode结点可能装不下，就需要分配新的块来存放这些索引信息。而文件的内容则多半是放在inode结点之外的，依靠inode里面的索引信息来找到它们。
比如ext2文件系统中，文件内容的索引结构如下（摘自《ULK3》）：


文件内容小于12个块的部分，其块号直接存放在inode中的i_block结构中；从第13块开始，使用一级间接索引，之后随偏移的增大又扩展到二级、三级间接索引。

对于目录，其内容一般是结构化的信息，描述了该目录下的文件的情况（主要包括每个文件的名字、inode号、等）。这是需要由具体的文件系统来解释的，用户看到这些原始内容是没有意义的。只有由具体文件系统将其解释为文件列表后，对用户才有意义。当用户程序寻找一个文件路径时，通过当前目录的inode，就能遍历到目录中的每一个结点（文件名+inode号）。匹配了下一级文件的名字以后，就能得到其对应的inode号，从而找到下一级文件的inode。这些下一级文件的信息也是因为其信息大小的不同，而直接存放在inode结点中，或另外的块中。
比如ext2文件系统中，目录信息结构如下（摘自《ULK3》）：



对于每一个下一级文件，记录了它的inode号、文件名、以及文件类型。

符号链接是一种特殊的文件。作为对另一个文件的代指，符号链接文件的内容就是它所代指的文件的路径。这个文件路径信息保存在inode或被inode引用的块中。具体的文件系统类型会实现其特定的读符号链接的方法。用户也可以通过readlink系统调用读到符号链接指向的文件路径。
在打开一个符号链接时，它代指的文件路径（也就是符号链接文件的内容）一般并不被用户程序所关心。内核会对此做一层包装，让用户程序自动访问到它所代指的文件的路径上去。

说了符号链接，也顺便提一下硬链接。硬链接并不会生成新的inode，而是同一个inode被包含在多个目录结点中，从而存在多个文件路径可以找到该文件。

super_block
前面描述了通过一个目录结点找到下一级文件的问题，那么文件系统中的第一个目录结点（也就是根目录）从哪里来呢？
每一个文件系统的实例中都有一个super_block（超级块），这就是该文件系统实例的源头。super_block里面主要有如下信息：根目录inode结点的结点号、inode号与块的对应信息、块的分配信息（总共有多少块、哪些已使用、等等）。
利用inode号与块的对应信息，就能知道一个结点号所对应的inode保存在什么地方。（这种对应信息也可以是某种约定，比如号码为N的inode，存放在M*N块上。）
通过super_block中的根目录inode号，在文件系统被挂载时就能得到其根目录结点。（根目录inode号也可以是具体文件系统约定的，比如约定1号inode就是根目录。）
此外，一个文件被创建之后，其大小是随时可能改变的。利用super_block中记录的块的分配信息，就能在文件增大时为其分配新的块、在文件减小只回收已经不需要使用的块。（这些信息并不是直接存放在super_block中，但是可以通过super_block找到它们，或者作为某种约定。比如约定super_block之后的块是某种结构化信息，块的分配信息就保存于其中。）

那么，这个super_block又从哪里来呢？这一般就只能是约定的了（比如约定第0个块就是super_block）。
我们知道，在使用一个磁盘之前，需要将它格式化一下，格式化成某种具体文件系统所支持的格式。这就包括在磁盘上生成super_block、根目录inode、以及一些必要的文件。并且按照该文件系统的约定，正确摆放它们的位置。

最后，以上提到的块号，实际上都是虚拟的块号。当一块磁盘被划分成若干分区时，每个分区都被当作一个设备，都拥有各自独立的块号。所以，如果super_block固定存放在0号块上，那么同一磁盘的分区0和分区1都有自己的0号块（它们分别对应到实际磁盘的两个不同的块上），从而都有自己的super_block。

块的缓存
在《linux文件读写浅析》中提到，存在一个磁盘高速缓存层，把文件的内容缓存在内存中。那么，文件内容以外的信息（比如inode）存在类似的缓存吗？

在linux上，设备也被当作是文件。读一个磁盘设备文件，能够读出磁盘上的原始数据。这些原始数据是什么呢？里面有super_block、inode、文件内容、还有一些脏数据（它们一般被文件系统理解为空闲空间）。同样，磁盘设备文件也像普通文件一样，拥有与之对应的磁盘高速缓存。当内核需要读磁盘上的某某块时（比如想读出存储在某块上的inode），实际上也是先在这个磁盘高速缓存上去寻找对应的内容，如果找不到再发起磁盘请求，并在读取到数据后更新磁盘高速缓存。
然而，类似inode的块读写与文件内容的读写还是不大一样。文件内容是连续的，具体文件系统在将文件内容存储在磁盘上时，也会尽量分配连续的块。这样，一次磁盘DMA，就可以读取若干个块，有益于效率。但像inode这样的东西却是孤立的，如果N号块是一个inode，N+1号块则很可能与之毫不相干。对一个inode的读写基本上是针对一个块的，不需要拥有像文件内容缓存那样的预读特性。
这两种缓存有着不同的名字，文件内容的缓存叫cache，inode之类的块缓存叫buffer（在linux下查看内存使用情况时，一般会分别看到buffer和cache的大小）。

在磁盘高速缓存中，缓存的单位是页（因为缓存是内存）。而一个内存页的大小往往是块大小的若干倍（常见值是：page为4K、block为1K），所以需要在磁盘高速缓存的内存页上再做一些细分，才能精确到块。在作为磁盘高速缓存页面的page结构上，附加buffer_head信息，如图（摘自《ULK3》）：



然后，在向通用块层发起磁盘读写请求时（参见《linux文件读写浅析》），bio的构造将是基于buffer_head的（而对于文件内容的读写，bio基于page来构造）。

之前有两篇文章整理过linux虚拟文件系统
的结构，和linux文件读写
的
流程。其中一些由具体文件系统类型来实现的地方并没有深入叙述，只是说这是由具体的文件系统来实现的。比如，读写文件的时候，文件的读写位置怎么对应到实
际的磁盘块呢？这是由具体的文件系统来实现的；再比如，寻找一个文件路径的时候，怎么知道XXX目录下是否有YYY文件存在呢？这也是由具体的文件系统来
实现的。

前些天同事问起linux下inode的含义，我也就此整理一下自己的思路，看看具体的文件系统大致需要实现什么样的功能，并且可以怎样去实现。


inode




先从inode说起。文件系统中的文件形成了一个树型结构，其中的每一个结点就是一个文件（目录也是文件），对应一个inode。inode的具体结构因
文件系统类型的不同而异，但是大体上应该包含如下信息：文件所有者（包括uid、gid）、权限位、文件大小、时间（创建时间、修改时间等）、文件内容。
其中最值得一说的是文件内容。

文件有目录和普通文件之分，这两者的内容有着不同的含义，其内容的组织也可能有着不同的结构。


对于普通文件来说，其内容就是用户能够看到的文件内容。当用户程序通过系统调用读写文件时，需要通过某种索引结构来知道文件中某个offset的数据应该
在哪个磁盘块上，然后转换成对该块的读写请求。当文件的内容很小时，文件内容的索引信息可以完全存放在inode结点中；如果文件很大，索引也会很
大，inode结点可能装不下，就需要分配新的块来存放这些索引信息。而文件的内容则多半是放在inode结点之外的，依靠inode里面的索引信息来找
到它们。

比如ext2文件系统中，文件内容的索引结构如下（摘自《ULK3》）：




文件内容小于12个块的部分，其块号直接存放在inode中的i_block结构中；从第13块开始，使用一级间接索引，之后随偏移的增大又扩展到二级、三级间接索引。


对于目录，其内容一般是结构化的信息，描述了该目录下的文件的情况（主要包括每个文件的名字、inode号、等）。这是需要由具体的文件系统来解释的，用
户看到这些原始内容是没有意义的。只有由具体文件系统将其解释为文件列表后，对用户才有意义。当用户程序寻找一个文件路径时，通过当前目录的inode，
就能遍历到目录中的每一个结点（文件名+inode号）。匹配了下一级文件的名字以后，就能得到其对应的inode号，从而找到下一级文件的inode。
这些下一级文件的信息也是因为其信息大小的不同，而直接存放在inode结点中，或另外的块中。

比如ext2文件系统中，目录信息结构如下（摘自《ULK3》）：




对于每一个下一级文件，记录了它的inode号、文件名、以及文件类型。


符号链接是一种特殊的文件。作为对另一个文件的代指，符号链接文件的内容就是它所代指的文件的路径。这个文件路径信息保存在inode或被inode引用
的块中。具体的文件系统类型会实现其特定的读符号链接的方法。用户也可以通过readlink系统调用读到符号链接指向的文件路径。

在打开一个符号链接时，它代指的文件路径（也就是符号链接文件的内容）一般并不被用户程序所关心。内核会对此做一层包装，让用户程序自动访问到它所代指的文件的路径上去。


说了符号链接，也顺便提一下硬链接。硬链接并不会生成新的inode，而是同一个inode被包含在多个目录结点中，从而存在多个文件路径可以找到该文件。


super_block




前面描述了通过一个目录结点找到下一级文件的问题，那么文件系统中的第一个目录结点（也就是根目录）从哪里来呢？

每一个文件系统的实例中都有一个super_block（超级块），这就是该文件系统实例的源头。super_block里面主要有如下信息：根目录inode结点的结点号、inode号与块的对应信息、块的分配信息（总共有多少块、哪些已使用、等等）。

利用inode号与块的对应信息，就能知道一个结点号所对应的inode保存在什么地方。（这种对应信息也可以是某种约定，比如号码为N的inode，存放在M*N块上。）

通过super_block中的根目录inode号，在文件系统被挂载时就能得到其根目录结点。（根目录inode号也可以是具体文件系统约定的，比如约定1号inode就是根目录。）

此外，一个文件被创建之后，其大小是随时可能改变的。利用super_block中记录的块的分配信息，就能在文件增大时为其分配新的块、在文件减小只回
收已经不需要使用的块。（这些信息并不是直接存放在super_block中，但是可以通过super_block找到它们，或者作为某种约定。比如约定
super_block之后的块是某种结构化信息，块的分配信息就保存于其中。）


那么，这个super_block又从哪里来呢？这一般就只能是约定的了（比如约定第0个块就是super_block）。

我们知道，在使用一个磁盘之前，需要将它格式化一下，格式化成某种具体文件系统所支持的格式。这就包括在磁盘上生成super_block、根目录inode、以及一些必要的文件。并且按照该文件系统的约定，正确摆放它们的位置。


最后，以上提到的块号，实际上都是虚拟的块号。当一块磁盘被划分成若干分区时，每个分区都被当作一个设备，都拥有各自独立的块号。所以，如果
super_block固定存放在0号块上，那么同一磁盘的分区0和分区1都有自己的0号块（它们分别对应到实际磁盘的两个不同的块上），从而都有自己的
super_block。


块的缓存




在《linux文件读写浅析
》中提到，存在一个磁盘高速缓存层，把文件的内容缓存在内存中。那么，文件内容以外的信息（比如inode）存在类似的缓存吗？


在linux上，设备也被当作是文件。读一个磁盘设备文件，能够读出磁盘上的原始数据。这些原始数据是什么呢？里面有super_block、
inode、文件内容、还有一些脏数据（它们一般被文件系统理解为空闲空间）。同样，磁盘设备文件也像普通文件一样，拥有与之对应的磁盘高速缓存。当内核
需要读磁盘上的某某块时（比如想读出存储在某块上的inode），实际上也是先在这个磁盘高速缓存上去寻找对应的内容，如果找不到再发起磁盘请求，并在读
取到数据后更新磁盘高速缓存。

然而，类似inode的块读写与文件内容的读写还是不大一样。文件内容是连续的，具体文件系统在将文件内容存储在磁盘上时，也会尽量分配连续的块。这样，
一次磁盘DMA，就可以读取若干个块，有益于效率。但像inode这样的东西却是孤立的，如果N号块是一个inode，N+1号块则很可能与之毫不相干。
对一个inode的读写基本上是针对一个块的，不需要拥有像文件内容缓存那样的预读特性。

这两种缓存有着不同的名字，文件内容的缓存叫cache，inode之类的块缓存叫buffer（在linux下查看内存使用情况时，一般会分别看到buffer和cache的大小）。


在磁盘高速缓存中，缓存的单位是页（因为缓存是内存）。而一个内存页的大小往往是块大小的若干倍（常见值是：page为4K、block为1K），所以需
要在磁盘高速缓存的内存页上再做一些细分，才能精确到块。在作为磁盘高速缓存页面的page结构上，附加buffer_head信息，如图（摘自
《ULK3》）：




然后，在向通用块层发起磁盘读写请求时（参见《linux文件读写浅析
》），bio的构造将是基于buffer_head的（而对于文件内容的读写，bio基于page来构造）。