1.页面和物理块
分页存储管理是将一个进程的逻辑地址空间分成若干个大小相等的片，称为页面或页，并为各页加以编号，从0开始，如第0页、第1页等。相应地，也把内存空间分成与页面相同大小的若干个存储块，称为(物理)块或页框(frame)，也同样为它们加以编号，如0＃块、1＃块等等。在为进程分配内存时，以块为单位将进程中的若干个页分别装入到多个可以不相邻接的物理块中。由于进程的最后一页经常装不满一块而形成了不可利用的碎片，称之为“页内碎片”。
在分页存储管理系统中的页面其大小应适中。页面若太小，一方面虽然可使内存碎片减小，从而减少了内存碎片的总空间，有利于提高内存利用率，但另一方面也会使每个进程占用较多的页面，从而导致进程的页表过长，占用大量内存；此外，还会降低页面换进换出的效率。然而，如果选择的页面较大，虽然可以减少页表的长度，提高页面换进换出的速度，但却又会使页内碎片增大。因此，页面的大小应选择得适中，且页面大小应是2的幂，通常为512 B~8 KB。
2.页表
在现有的大部分编程模式中，每个进程都有自己的虚拟地址空间，但是该虚拟地址空间最终还是需要映射到实际的物理内存地址上，这种管理虚拟地址和物理地址映射关系的数据是由页表来维护的。
3.如何加快虚拟地址和物理地址的转换？
当程序访问对应进程的虚拟地址时，硬件通过页表执行“页表遍历”来转换地址。当转换以页面粒度进行维护时，整个过程会变得更容易。但它仍然不是很便宜，而且每次访问内存时都需要这样做！因此，还有一个小的缓存，用于存储最新的转换，这就是转译后备缓冲器(Translation Lookaside Buffer，TLB)。TLB 通常非常小，少于 100 个条目，因为它至少需要与 L1 缓存一样快，甚至更快。对于许多工作负载，TLB 未命中和相关的页表遍历需要花费大量时间。
4.如何解决缓存未命中场景下效率低的问题？
既然我们无法将转译后备缓冲器(Translation Lookaside Buffer，TLB) 做得更大，我们可以做其他事情：制作更大的页面！大多数硬件都有 4K 基本页面和 2M/4M/1G“大页面（Huge Pages，HP）”。使用更大的页面来覆盖同一区域也会使页表本身更小，从而降低页表遍历的成本。
5.实现大页面（Huge Pages，HP）的方法
5.1.hugetlbfs。
具体方法为切出系统内存的一部分，将其公开为虚拟文件系统，并让应用程序mmap(2)使用它。这是一个特殊的接口，需要操作系统配置和应用程序更改才能使用。这也是“全有或全无”的交易：分配给 hugetlbfs（持久部分）的空间不能由常规进程使用。
5.2.透明大页面 (Huge Transparent Pages)。
让应用程序照常分配内存，但尝试向应用程序透明地提供大页面支持的存储。理想情况下，不需要对应用程序进行任何更改，但我们将看到应用程序如何从了解 THP 可用中受益。但在实践中，存在内存开销（因为您将为小东西分配整个大页面）或时间开销（因为有时 THP 需要对内存进行碎片整理以分配页面）。好的部分是有一个中间立场：madvise(2)让应用程序告诉 Linux 在哪里使用 THP。
6.相关JVM参数
-XX:+UseHugeTLBFS将 Java 堆映射到 hugetlbfs 中，这应该单独准备。
-XX:+UseTransparentHugePages只需madvise-s 即可让 Java 堆使用 THP。这是一个方便的选项，因为我们知道 Java 堆很大，大部分是连续的，并且可能从大页面中受益最多。
-XX:+UseLargePages是一个通用的快捷方式，可以启用任何可用的功能。在 Linux 上，它启用 hugetlbfs，而不是 THP。我猜这是出于历史原因，因为 hugetlbfs 先出现。
7.应用场景
当应用程序有大量数据和大堆时，具体如例如大规模数据库、内存缓存、科学计算等。
