在Linux抽象一切皆文件
缓冲区
数据App-x
PageCachekernel的折中方案
stack
read（fd8）
受内核影响
程序的虚拟线性地址
内核
MappedByteBuffer逻辑地址
App
物理内存
data
pc4k
目录树结构趋向于稳定有一个映射的过程
App拿到FD有指针或者seek偏移量的概念
数据App2-x
page cache
数据App-y
ByteBuffer
put()不会产生系统调用
System Call系统调用
基础概念
Buffered IO 和 普通的IO 谁快 Buffered IO快span style=\
-Xmx 1GJVM heap
Buffer
硬盘
数据会进行分片从虚拟线性地址映射到物理内存不一定是连续的，以page为单位默认4k不会进行全量分配
冯诺依曼计算器，控制器，主存储器输入输出设备 I/O
lsof -p $$ 进程打开了那些文件 $$指当前bash进程
allocateDirect堆外分配
-：普通问文件（可执行，图片，文本）REGd：目录b：块设备l：连接（软连接（Inode不同，删除元数据会报错），硬连接：两个指向同一个物理位置Inode）修改任意都会变化c：字符设备 CHRs：socketp：pipeline[eventpoll]：内核提供的区域
page cache优化IO性能但是会丢失数据
txt
网络
IO
channel.readchannel.write
写入
allocate堆上分配
协处理器DMA
CPUMMU
Kernel
page cache内核维护 中间层使用多大的内存是否淘汰是否延时，是否丢数据
kernelVFS 树FDinodepagecachedirtyflush
Java 进程 Linux Procedure
FileChannel
on heap
pos
如果App中的table中1-10映射了物理内存中的30-40这个时候App-z想要访问物理内存中的80就会导致缺页就会从用户态切换到内核态去分配page再切换回用户态
文件类型
创建
off heap
数据App-z
VFS 虚拟文件管理系统FD 下面的包装 文件的描述inode 文件在内存中的Idpagecache 默认4k 多个App共同访问一个时共享dirty app修改过文件之后会标记为dirty
cap
limit
依赖
CPU
heap
寄存器
map
Page Cache第一次创建的时候为Dirty当写入到磁盘的时候会去掉Dirty当进行修改的时候又变回Dirty但是都是Cache的状态
文件标识符任何程序都有0：标准输入1：标准输出2：报错输出
修改
I/O
OS 没有绝对的数据可靠性为什么设计pagecache，减少硬件IO调用，优先使用内存即便你想要可靠性 调成最慢的方式但是单点问题会让你的性能损耗 一毛钱收益都没有主从复制 主备HA
/proc/proc/$$$$ 当前bash的PID $BASHPID $$优先级高于|/proc/$$/fd 文件描述符 lsof -op $$ 细节重定向：不是命令 是机制输入 输出< >管道：前面的输出作为后面的输入
磁盘
性能稍高
App不能直接操作硬件，需要通过内核
