内存访问效率的比较相对比较复杂一点，主要是内存访问有多种场景：
（1）大批量的，连续地址块的内存数据读写。这种测试环境下得到的性能数据是内存带宽，性能瓶颈主要在内存芯片的性能上；
（2）随机内存访问性能。这种测试环境下的性能数据主要与内存带宽、cache的命中率和虚拟地址与物理地址转换的效率等因素有关。
以下将主要针对这两种内存访问场景进行分析。在分析之前我们先概要说明一下Docker和虚拟机的内存访问模型差异。下图是Docker与虚拟机内存访问模型：
可见在应用程序内存访问上，虚拟机的应用程序要进行2次的虚拟内存到物理内存的映射，读写内存的代价比Docker的应用程序高。
下图是场景（1）的测试数据，即内存带宽数据。左图是程序运行在一块CPU（即8核）上的数据，右图是程序运行在2块CPU（即16核）上的数据。单位均为GB/s。
从图中数据可以看出，在内存带宽性能上Docker与虚拟机的性能差异并不大。这是因为在内存带宽测试中，读写的内存地址是连续的，大批量的，内核对这种操作会进行优化（数据预存取）。因此虚拟内存到物理内存的映射次数比较少，性能瓶颈主要在物理内存的读写速度上，因此这种情况Docker和虚拟机的测试性能差别不大;
内存带宽测试中Docker与虚拟机内存访问性能差异不大的原因是由于内存带宽测试中需要进行虚拟地址到物理地址的映射次数比较少。根据这个假设，我们推测，当进行随机内存访问测试时这两者的性能差距将会变大，因为随机内存访问测试中需要进行虚拟内存地址到物理内存地址的映射次数将会变多。结果如下图所示。
左图是程序运行在一个CPU上的数据，右图是程序运行在2块CPU上的数据。从左图可以看出，确实如我们所预测的，在随机内存访问性能上容器与虚拟机的性能差距变得比较明显，容器的内存访问性能明显比虚拟机优秀；但出乎我们意料的是在2块CPU上运行测试程序时容器与虚拟机的随机内存访问性能的差距却又变的不明显。
针对这个现象，IBM的论文给出了一个合理解释。这是因为当有2块CPU同时对内存进行访问时，内存读写的控制将会变得比较复杂，因为两块CPU可能同时读写同一个地址的数据，需要对内存数据进行一些同步操作，从而导致内存读写性能的损耗。这种损耗即使对于物理机也是存在的，可以看出右图的内存访问性能数据是低于左图的。2块CPU对内存读写性能的损耗影响是非常大的，这个损耗占据的比例远大于虚拟机和Docker由于内存访问模型的不同产生的差异，因此在右图中Docker与虚拟机的随机内存访问性能上我们看不出明显差异。 Docker与虚拟机启动时间及资源耗费比较
上面两个小节主要从运行在Docker里的程序和运行在虚拟机里的程序进行性能比较。事实上，Docker之所以如此受到开发者关注的另外一个重要原因是启动Docker的系统代价比启动一台虚拟机的代价要低得多：无论从启动时间还是从启动资源耗费角度来说。Docker直接利用宿主机的系统内核，避免了虚拟机启动时所需的系统引导时间和操作系统运行的资源消耗。利用Docker能在几秒钟之内启动大量的容器，这是虚拟机无法办到的。快速启动、低系统资源消耗的优点使Docker在弹性云平台和自动运维系统方面有着很好的应用前景。
Docker的劣势