indows自带的文件搜索功能，分分钟让人想抓狂；每次想找一个什么文件，搜索完了之后半天进度条还在读取中，简直无法直视。
那么，今天给你介绍几个Windows多标签资源管理器和文件搜索神器，让效率和速度分分钟快到飞起来！
Everything是一款秒速的电脑文件搜索工具，除了第一次打开需要建立索引，以后每次输入关键字，文字还没打完结果几乎就已经出来了。速度快的让人叹为观止，超越你对Windows文件的搜索认知！
如果你经常需要找文件，一定不能错过这款小软件，而且软件完全免费、界面简洁、体积小巧，根本不用担心占用内存问题。
QTTabBar的功能到底有多强大？
当鼠标划过目录时，如果该目录有子目录，就会在目录的右下角出现一个小箭头，点击箭头即会跳出子选单让你能够快速选择目录下的文件。
软件目前支持以下系统：
Windows7&Windows8&Windows8.1&Windows10(32bit/64bit)
Listary是一款Windows文件浏览增强工具，为Windows资源管理器增加收藏功能、最近文档和智能命令。还可与第三方程序集成，比如强大的TotalCommander。文件小、功能强大，秒杀系统自带搜索功能！
几个实用的快捷键：
Win+G：激活Listary工具栏
Ctrl+1、2、3：可以快搜打开收藏、最近文档、智能命令（其中每项功能都可以自定义快捷键）。
网页搜索功能
可以添加任何你想快速搜索的网站，只需在listary选项设置-关键字中添加；比如“bd+空格+关键词”，进行Listary一键快速搜索，还可以添加京东、淘宝、天猫、微博等网站。
Lisrary一个实用小功能
当需要打开某一个文件或要给文件选择一个另存为的位置时，只要你的资源管理器打开该文件位置，选择时按住快捷键Ctrl+G，listary会自动定位到该位置，不用每次都一层一层打开进行选择。
需要获取这几个软件的下载地址，可在我们的头条号“斜杠指南”中，私信数字：26
计算机组成中内存或者叫主存是非常重要的部件。内存因为地位太重要，所以和CPU直接相连，通过数据总线进行数据传输，并通过地址总线来进行物理地址的寻址。
除了数据总线、地址总线还有控制总线、IO总线等。IO总线是用来连接各种外设的，例如USB全称就是通用串行总线。再比如PCIE是目前最常见的IO总线之一。这里放一张B站硬件茶谈的一张图。
图1-1硬件图
图中CPU和左侧内存条直接连，并通过PCIE总线与下方的PCIE插槽连接，在PCIE插槽上可以插显卡，网卡，声卡，硬盘等等。PCIE带宽是共享的，如果某个设备用了x1路带宽，则能用的就少一路，因为本质上每一路都是串行的。南桥和CPU之间也有PCIE通道，主要是提供给一些带宽占用很低的外设。
南桥芯片位于主板上，一般在右下角，有个被动散热下面压着。南桥中有个很重要的设备就是DMA控制器，或者叫DMAC。DMA直接内存访问，意思就是DMAC能够直接访问内存。即一般进行IO的时候，cpu会把总线完全交给DMAC（DMAC和CPU会分时掌控总线），DMAC访问设备如磁盘，将数据读到内存中，因为此时接管了总线，所以可以写内存。在这个过程中CPU可以进行其他的任务。这也是异步IO、非阻塞IO等理论的基础。
计算机常考题：
图1-2-1题目1
图1-2-2题目2
win32程序从程序上能操作的逻辑地址空间有4G这么大（虽然实际可能用不了那么多），4G的逻辑地址需要全部映射到物理内存上。映射的最小单位如果是字节的话，映射表将会非常大，且效率低下。提出page概念，即最小的映射单位是一个page，一页一般是4K这样的大小，我的机器是这样的，所以下面程序demo中页大小都是4K。
显然逻辑空间可能比实际要大，但是只要程序没有用那么多内存，就不需要去映射那么多page，且就算用了那么多内存，也可以映射到磁盘上。
逻辑页是抽象的，需要映射到物理的页上，才能完成对内存的操作。我们把逻辑页叫页（page）物理页叫帧（pageframe）。页号-帧号的映射表叫页表（pagetable）。
图2-1页表映射
图2-2页表映射
同时每个进程都有自己的专属页表，如下：
图2-3多进程的页表
一种实际情况，4G逻辑地址有32bit地址空间，假设pageSize=4K偏移量占12bit，因而页表的逻辑页号有20bit。再假设实际内存条只有256M28bit地址空间12bit偏移量16bit页号。
逻辑地址0x000011a3，去映射的时候00001就是逻辑页号，去查页表发现映射到真实页帧号00f3，然后偏移量不变还是1a3，最终就找到这个物理内存内容了。
图2-4页表的映射过程
逐出的过程需要判断当前物理页(帧)是否是脏的（脏：与磁盘中内容不一致，即从磁盘加载到物理内存后被改过就是脏的），如果是脏的还需要更新磁盘中的内容保证一致。
逐出后就腾出了位置给从磁盘中读到的这页的数据，然后需要更新页表的这一项的映射关系，将磁盘改为帧号，然后重新进行查页表这一步。
一个地址中“住”的是一字节(8bit)的数据。
上面提到了逻辑-物理页的映射，这就是页表，但是上面的页表其实除了简单的页号映射，还存储了其他一些属性：是否有效，读写权限，修改位，访问位（淘汰算法和TLB中用），是否是脏（被修改过就是脏的，因为他和硬盘上的数据不一致），是否允许被高速缓存等等。
页表存于主存中，每个进程都有自己的页表。
上面可以看到基于页表的寻址，需要两次访问主存（页表是存在主存的），效率低下。为了提高速度，引入了快表，快表是页表项的缓存，将最近一次的映射项存入快表，因为空间有限所以需要逐出最老的那一项。快表的设计是基于经验：程序经常访问的page一般就那几个，不会经常频繁的更换特别多的页。
快表可能存于硬件MMU中（也可能是软件TLB），一般只有8-256条，每个进程都有自己的快表。
另一个值得讨论的话题是页表占用空间太大，上面例子中（32位程序256M机器pageSize4K）页号有20bit即2百万个，所以需要有1百万条，每条大小如果只算逻辑页号(20bit)和物理页号(16bit)的话：
36bit*2^20=4.5MB如果有64个这样的程序在运行...后果可想而知。
一种很好的解决方法是多级页表，第一级页表用于寻找第二级页表的编号。<20bit-16bit>的单级映射可以改成<10bit-10bit>和<10bit-6bit>两级映射。此时占用内存为
20bit*2^10+16bit*2^20=2M2.3分段严格意义的分段是，每一段的虚拟地址都是从0开始。然后页表是段号+页号来映射帧号的。但是这种形式已经被废弃了，只有x8632位的intel的cpu还保留了这种段页结合的方式，即严格意义的分段已经用的很少。
那为什么还经常听到段的概念？现在所说的段一般是程序在逻辑层面保留的概念，对逻辑地址有个粗略的划分，便于程序编写，但是并不影响os的内存管理（还是分页管理）。
以32位程序为例，在逻辑空间中最高的0xc0000000-0xffffffff这1G的内存是给内核留出的，这部分是所有进程共享的。剩余3G内存从低到高分别是Text、Data、Heap、Lib、Stack。64位程序则远大于这里的值。
Heap是从低往高增长，Stack是从高往低增长，且有个最大限制。Data存储静态变量Text存储程序二进制码，Lib存储库函数需要占用的内存，多个程序如果都使用了相同的库，内存是共用的（共享内存）。各个部分的留有随机的一段偏移量，可以保护程序，这也使得每次重新执行程序的时候变量所在的内存地址总是不同的。
图2-532位系统下内存地址的组成
分段是逻辑空间上的，不影响分页的内存管理方式，后面进行分页，映射到物理内存上各部分跨多个页其实并不连续。
cpu的三级缓存扮演着缓存主存数据的作用，而cache在内存管理中的位置是怎样的呢？
PIPT，物理级cache，cpu分析完映射关系，先到cache找有没有该物理地址的cache。这样会非常的慢，但是所有进程可以共享cache。
VIVT，逻辑级cache，cpu直接通过逻辑地址找cache，miss后再查TLB页表这些。这样很快，但是逻辑地址只能对当期进程使用，其他进程完全不能复用，尤其是库函数这种共享的不能利用好cache。
VIPT，将两者结合，用逻辑地址查找cache，cache中数据部分前面添加一个对应物理地址的tag。这样拿到这个tag后到tlb、页表中查看下这个对应关系是否正确，如果正确就直接读cache。这样速度和共享性都是折中的。
以上三种方式各有优劣，在不同的cpu中可能使用的不一样。
很多人想当然的会认为32位系统的虚拟地址是32位，这是没错的，但是64位系统下真正的可用的虚拟地址却不到64位。
明显看到是48位，虽然这个指针大小是8byte，但是只有48bit是有效的地址位，前面是多个0。通过cat/proc/cpuinfo最后几行能看到物理地址和虚拟地址的大小，这主要是cpu单方面定制的，我的这台机器是13年买的intel酷睿i53230的CPU。当然我的系统内存只有2G，其实物理地址不会有43位，只是cpu最多支持43位物理地址。
图2-7cpuinfo中的虚拟地址和物理地址
小细节：栈是仅次于内核的高位地址，参考图2-5.所以看到前面这个地址基本能推算出分给内核的虚拟空间应该是0xffffffffffff-0x800000000000。
在生活中我们经常看到各种内存的种类，比如在linux调用free-h的时候可以看到图2-6的分类。
在linux中通过free-h可以看到当前系统的内存情况:
图2-8free指令下的内存分类
mem是物理内存，swap是交换分区，是用来将内存暂时放到磁盘上的。
total总内存大小，used用户使用的内存大小，free空闲的内存大小，shared共享内存大小，buff/cache文件缓存大小，available可用内存大小是free和buff/cache加起来。
total=used（含shared）+free+buff/cache
这里需要理解buff/cache，他们在老一些的内核中是分开显示的分别是buffercache和pagecache，都是对磁盘的缓存。其中buffercache是硬件层面，对磁盘块中的数据进行缓存，缓存的单位当然也是块。而pagecache是文件系统层面，对文件进行缓存，缓存单位就是页。buffercache的提出非常的早，两者并存时会遇到重复缓存了相同的内容的情况。
较新的内核已经将两者合并，或者说将buffercache合到了pagecache。虽然也还是能缓存磁盘块，但是存储单位也是页了。并且buffer使用前会先检查pagecahce是否已经缓存了对应内容，如果是则直接指过去。在机器维度查看内存的时候也能发现BufferCache都是0，因为都合到了pageCache，有Buffer的都是很老的内核的机器。
buff/cache占用大，会不会影响后续程序申请内存？
不会，一旦用户程序需要申请内存，buff/cache就会释放掉一部分。换句话说buff/cache是在内存比较空闲的时候，尽量利用一下来加速文件读写的。如果有大哥需要用内存，是会拱手让出的。
在windows任务管理器中又可以看到下图的几种状态的内存叫法，而在Jprofile查看jvm内存的时候也有图2-8的一些叫法。
图2-9windows任务管理器内存分类
图2-10jprofile内存分类
已提交的意思是已经向操作系统申请了这么多的内存，操作系统可以已经给了这么多内存了，但是也可能没有给那么多。贴一张微软自己的解释如图
图2-11几种内存的解释
提交的内存因为是虚拟内存，并不一定系统会立刻给这么多，所以可能提交远超过物理内存上限的大小。我之前看过一个视频，小哥用malloc申请了130000+GB的内存程序才退出，而如果在malloc后给申请的地址填写值，事情就不那么顺利了。感兴趣可以去看下这个视频。当然不了解C语言也没关系我在本文后半段会用java的Unsafe同样申请超过物理上限的内存大小做demo。
内核态、用户态、内核空间、用户空间，是经常说起的概念。因为操作系统不允许用户直接操作硬件，所以需要用户程序通知内核，内核帮你下达指令给硬件。在进行读文件的时候，就需要用到磁盘这个设备，所以需要进入内核态，将文件内容读到内核buffer，然后拷贝到用户buffer并从内核态切换为用户态，程序才能真正拿到数据。
用户态进内核态，一般有三种触发条件，中断、异常和系统调用，中断和异常有时候界限比较模糊，例如缺页中断也有地方叫缺页异常。这里我们引出了系统调用，大多数需要主动操作或读写硬件的都是通过系统调用。例如读写文件的open/read/write是系统调用，网络传输常见的select/poll/epoll也是系统调用，申请内存的malloc底层也是通过brk或mmap这俩系统调用实现的。
系统调用伴随了很多设计的优化，例如通过epoll等系统调用实现的IO多路复用提高了网络包的处理效率，mmap、sendfile等系统调用实现的零拷贝，减少了用户空间和内核空间之间的数据拷贝和上下文切换次数等等。在java的NIO中有大量的函数是直接封装了系统调用。
malloc小于128K（阈值可修改）的内存时，用的是brk申请内存。C语言中sbrk(可函数)是brk(系统调用)的简单封装，下面代码打印的值可以看出first因为申请了0大小，所以和second指针位置相同。而third则表示的是second的尾部地址。可以看到虚拟地址是连续分配的，brk其实就是向上扩展heap的上界，配合查看图2-5。
如果此时在third+1地址处去初始化一个int值，是可以成功的，并不报错。
#include
void*second=sbrk(4096);图3-2brk代码输出2
malloc大于128K的内存时，用的是mmap。
//addr传NULL则不关心起始地址，关心地址的话应传个4k的倍数，不然也会归到4k倍数的起始地址。void*mmap(void*addr,size_tlength,intprot,intflags,intfd,off_toffset);//释放内存munmapintmunmap(void*addr,size_tlength);
mmap用法有两种，一种是将文件映射到内存，另一种空文件映射，也就是把fd传入-1，就会从映射区申请到一块内存。malloc就是调用的第二种实现。
#include
图3-3进程的内存minflt
这里是mmap内存的惰性加载，一开始mmap100页时其实都没有分配给进程，在用到的时候开始真正拿到内存，此时触发minflt缺页，因为不是映射的文件，不用从磁盘中调内存，所以是小错误。但是仍是消耗性能的。
如果mmap是映射的磁盘文件，也会惰性加载，在初次加载或者页被逐出后再加载的时候，也会缺页，这个时候就不是小错误minflt了，而是majflt。例如下面使用mmap来读文件。
图3-3-2进程mmap读文件引发majflt
read和mmap都可以读文件，前者有状态转换和多次拷贝，但是后者有缺页中断。在单纯读磁盘文件场景，两者其实没法在孰优孰劣上有定论。
图3-4共享内存的典型例子
共享内存原理就是两个进程中页，映射到了相同的帧。代码这里不写了，直接参考geeks这篇的代码。
图4-1java的内存五区
我们这里来看下Klass，有没有想过我们反射的时候操作的都是Class对象而不是这里的Klass，两者关系是:
Klass是C++对象InstanceKlass，里面有个_java_mirror字段指向对应的Class对象。
图4-2java对象头指向metaspace
这里还提到了指针压缩，64位系统，如果jvm堆内存小于32GB是可以开启指针压缩的，此时Klass指针只需要4个字节，同时对象指针也只需要4个字节。这里会衍生出两个问题：
第一个就是4字节最多表示2^32个地址，每个地址里住的是一个字节，所以只能表示4GB，怎么还说32G下都能压缩呢？
因为：上面提到对象都是8字节对齐，所以每个地址里住的是8字节，所以可以表示32GB，实际地址移3位。
第二个问题就是普通对象指针压缩CompressedObjectPointers(“CompressedOops”)，压缩的是java堆上的对象的指针(引用)大小，而对象头指向的是Klass，这是个C++的结构，这个指针也压缩了吗？
是的，CompressOops和CompressKlass是相伴而生，默认同时开启的，Klass这部分需要连续的<4G的内存，因为是C++结构，没有8字节对齐限制，所以4字节只能在4G内存上寻址，默认大小是1G。
metaspace存储的是类的元数据信息，上面提到的Klass就是在metaspace中的，一般开启压缩的metaspace有CompressClassSpace和NonClassSpace两部分组成，其中前者内存占用较少，是后者的5-100分之一，前者又叫压缩类空间，实际上这部分内存本身并没有压缩，只是对象头中记录的指向这里的指针进行了压缩。
图4-3metaspace两部分：非类区和压缩类空间
图4-4指针压缩开启时非堆
将压缩类空间和非类空间分开的原因之一，就是压缩类空间是对象关联的，只有4G上限，而将更多其他元数据剥离出去后，元空间可以远超过4G。而如果不开启指针压缩，其实两者就没必要分开了。关闭指针压缩后，-XX:-UseCompressedOops两部分会合为一个。统称Metaspace
图4-5指针压缩关闭时非堆
一个新的类在需要被加载的时候，会使用ClassLoader在元空间申请内存，并存储类的元数据信息。
元空间的内存是ClassLoader持有的，所以说只有对应的ClassLoader卸载掉的时候才会释放。ClassLoader又是需要他所加载的类都消失的时候才能消失。一般是伴随在一次GC的过程中进行这个释放。另外元空间如果超过了上限也会导致OOM。
当然会导致OOM，所以metaspace限制大小的配置，需要根据程序谨慎定制。一般通过不断创建新的类，如加载新类（如hsf配置中下发groovy文件就会动态的加载新的class），或者动态代理类（spring中的增强类都是动态代理类）都会导致metaspace的增长。
图4-5a压缩类空间
图4-5b非类空间
上面的CodeCache和Metaspace毫无疑问是jvm管理下的堆外空间。但是除了这些常规的堆外空间，jvm还可以使用一些native方法，直接申请堆外内存。
例如做这么个demo，我们设置一个简单的java程序的堆大小是10M，此时用jprofile查看内存堆提交了10M实际使用9M多，堆外提交了12M实际使用11M左右。所以算下来是20M+。直接查看进程内存会略大于这个值，因为这个20M是虚拟机内部的内存，本身运行还是需要一些额外内存的，进程提交的内存有90M，实际使用内存47M
图4-6进程的提交内存和实际内存
接下来我们使用Unsafe申请1G堆外内存（也可以用NIO中的ByteBuffer.allocateDirect()）
图4-7进程的提交内存和实际内存2
我甚至可以调整申请65G的内存，要知道我的电脑也只有64G的内存，但这仍不会报错，可以看到提交的内存已经超过了物理内存上限，但是得益于前面讲的虚拟内存的管理模式，使得应用申请了超过物理大小的内存，而如果真的使用起来的话，会有页置换来协调。
图4-8进程可以提交超过现实存在的内存
上面的提交内存很大但是实际使用内存却并不大：
图4-9任务管理器此时的状态
Unsafe是很危险的一个类，不建议使用。但是可以帮助我们理解有些框架是如何工作的。比如前一阵子看的Ehcache就提供了堆外缓存就是用类似Unsafe申请的。堆外缓存需要自己实现序列化，因为Unsafe设置内存只能设置01字节码不能设置为java对象。
堆外内存的坏处：序列化需要自己实现，清理也需要自己实现，访问速度比heap要慢。