网上科普有关“深入理解Java虚拟机的目录”话题很是火热，小编也是针对深入理解Java虚拟机的目录寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望能够帮助到您。

前言

致谢

第一部分 走近Java

第1章 走近Java / 2

1.1 概述 / 2

1.2 Java技术体系 / 3

1.3 Java发展史 / 5

1.4 展望Java技术的未来 / 9

1.4.1 模块化 / 9

1.4.2 混合语言 / 9

1.4.3 多核并行 / 11

1.4.4 进一步丰富语法 / 12

1.4.5 64位虚拟机 / 13

1.5 实战：自己编译JDK / 13

1.5.1 获取JDK源码 / 13

1.5.2 系统需求 / 14

1.5.3 构建编译环境 / 15

1.5.4 准备依赖项 / 17

1.5.5 进行编译 / 18

1.6 本章小结 / 21

第二部分 自动内存管理机制

第2章 Java内存区域与内存溢出异常 / 24

2.1 概述 / 24

2.2 运行时数据区域 / 25

2.2.1 程序计数器 / 25

2.2.2 Java虚拟机栈 / 26

2.2.3 本地方法栈 / 27

2.2.4 Java堆 / 27

2.2.5 方法区 / 28

2.2.6 运行时常量池 / 29

2.2.7 直接内存 / 29

2.3 对象访问 / 30

2.4 实战：OutOfMemoryError异常 / 32

2.4.1 Java堆溢出 / 32

2.4.2 虚拟机栈和本地方法栈溢出 / 35

2.4.3 运行时常量池溢出 / 38

2.4.4 方法区溢出 / 39

2.4.5 本机直接内存溢出 / 41

2.5 本章小结 / 42

第3章 垃圾收集器与内存分配策略 / 43

3.1 概述 / 43

3.2 对象已死？ / 44

3.2.1 引用计数算法 / 44

3.2.2 根搜索算法 / 46

3.2.3 再谈引用 / 47

3.2.4 生存还是死亡？ / 48

3.2.5 回收方法区 / 50

3.3 垃圾收集算法 / 51

3.3.1 标记 -清除算法 / 51

3.3.2 复制算法 / 52

3.3.3 标记-整理算法 / 54

3.3.4 分代收集算法 / 54

3.4 垃圾收集器 / 55

3.4.1 Serial收集器 / 56

3.4.2 ParNew收集器 / 57

3.4.3 Parallel Scavenge收集器 / 59

3.4.4 Serial Old收集器 / 60

3.4.5 Parallel Old收集器 / 61

3.4.6 CMS收集器 / 61

3.4.7 G1收集器 / 64

3.4.8 垃圾收集器参数总结 / 64

3.5 内存分配与回收策略 / 65

3.5.1 对象优先在Eden分配 / 66

3.5.2 大对象直接进入老年代 / 68

3.5.3 长期存活的对象将进入老年代 / 69

3.5.4 动态对象年龄判定 / 71

3.5.5 空间分配担保 / 73

3.6 本章小结 / 75

第4章 虚拟机性能监控与故障处理工具 / 76

4.1 概述 / 76

4.2 JDK的命令行工具 / 76

4.2.1 jps：虚拟机进程状况工具 / 79

4.2.2 jstat：虚拟机统计信息监视工具 / 80

4.2.3 jinfo：Java配置信息工具 / 82

4.2.4 jmap：Java内存映像工具 / 82

4.2.5 jhat：虚拟机堆转储快照分析工具 / 84

4.2.6 jstack：Java堆栈跟踪工具 / 85

4.3 JDK的可视化工具 / 87

4.3.1 JConsole：Java监视与管理控制台 / 88

4.3.2 VisualVM：多合一故障处理工具 / 96

4.4 本章小结 / 105

第5章 调优案例分析与实战 / 106

5.1 概述 / 106

5.2 案例分析 / 106

5.2.1 高性能硬件上的程序部署策略 / 106

5.2.2 集群间同步导致的内存溢出 / 109

5.2.3 堆外内存导致的溢出错误 / 110

5.2.4 外部命令导致系统缓慢 / 112

5.2.5 服务器JVM进程崩溃 / 113

5.3 实战：Eclipse运行速度调优 / 114

5.3.1 调优前的程序运行状态 / 114

5.3.2 升级JDK 1.6的性能变化及兼容问题 / 117

5.3.3 编译时间和类加载时间的优化 / 122

5.3.4 调整内存设置控制垃圾收集频率 / 126

5.3.5 选择收集器降低延迟 / 130

5.4 本章小结 / 133

第三部分 虚拟机执行子系统

第6章 类文件结构 / 136

6.1 概述 / 136

6.2 无关性的基石 / 136

6.3 Class类文件的结构 / 138

6.3.1 魔数与Class文件的版本 / 139

6.3.2 常量池 / 141

6.3.3 访问标志 / 147

6.3.4 类索引、父类索引与接口索引集合 / 148

6.3.5 字段表集合 / 149

6.3.6 方法表集合 / 153

6.3.7 属性表集合 / 155

6.4 Class文件结构的发展 / 168

6.5 本章小结 / 170

第7章 虚拟机类加载机制 / 171

7.1 概述 / 171

7.2 类加载的时机 / 172

7.3 类加载的过程 / 176

7.3.1 加载 / 176

7.3.2 验证 / 178

7.3.3 准备 / 181

7.3.4 解析 / 182

7.3.5 初始化 / 186

7.4 类加载器 / 189

7.4.1 类与类加载器 / 189

7.4.2 双亲委派模型 / 191

7.4.3 破坏双亲委派模型 / 194

7.5 本章小结 / 197

第8章 虚拟机字节码执行引擎 / 198

8.1 概述 / 198

8.2 运行时栈帧结构 / 199

8.2.1 局部变量表 / 199

8.2.2 操作数栈 / 204

8.2.3 动态连接 / 206

8.2.4 方法返回地址 / 206

8.2.5 附加信息 / 207

8.3 方法调用 / 207

8.3.1 解析 / 207

8.3.2 分派 / 209

8.4 基于栈的字节码解释执行引擎 / 221

8.4.1 解释执行 / 221

8.4.2 基于栈的指令集与基于寄存器的指令集 / 223

8.4.3 基于栈的解释器执行过程 / 224

8.5 本章小结 / 230

第9章 类加载及执行子系统的案例与实战 / 231

9.1 概述 / 231

9.2 案例分析 / 231

9.2.1 Tomcat：正统的类加载器架构 / 232

9.2.2 OSGi：灵活的类加载器架构 / 235

9.2.3 字节码生成技术与动态代理的实现 / 238

9.2.4 Retrotranslator：跨越JDK版本 / 242

9.3 实战：自己动手实现远程执行功能 / 246

9.3.1 目标 / 246

9.3.2 思路 / 247

9.3.3 实现 / 248

9.3.4 验证 / 255

9.4 本章小结 / 256

第四部分 程序编译与代码优化

第10章 早期（编译期）优化 / 258

10.1 概述 / 258

10.2 Javac编译器 / 259

10.2.1 Javac的源码与调试 / 259

10.2.2 解析与填充符号表 / 262

10.2.3 注解处理器 / 264

10.2.4 语义分析与字节码生成 / 264

10.3 Java语法糖的味道 / 268

10.3.1 泛型与类型擦除 / 268

10.3.2 自动装箱、拆箱与遍历循环 / 273

10.3.3 条件编译 / 275

10.4 实战：插入式注解处理器 / 276

10.4.1 实战目标 / 276

10.4.2 代码实现 / 277

10.4.3 运行与测试 / 284

10.4.4 其他应用案例 / 286

10.5 本章小结 / 286

第11章 晚期（运行期）优化 / 287

11.1 概述 / 287

11.2 HotSpot虚拟机内的即时编译器 / 288

11.2.1 解释器与编译器 / 288

11.2.2 编译对象与触发条件 / 291

11.2.3 编译过程 / 294

11.2.4 查看与分析即时编译结果 / 297

11.3 编译优化技术 / 301

11.3.1 优化技术概览 / 301

11.3.2 公共子表达式消除 / 305

11.3.3 数组边界检查消除 / 307

11.3.4 方法内联 / 307

11.3.5 逃逸分析 / 309

11.4 Java与C/C++的编译器对比 / 311

11.5 本章小结 / 313

第五部分 高效并发

第12章 Java内存模型与线程 / 316

12.1 概述 / 316

12.2 硬件的效率与一致性 / 317

12.3 Java内存模型 / 318

12.3.1 主内存与工作内存 / 319

12.3.2 内存间交互操作 / 320

12.3.3 对于volatile型变量的特殊规则 / 322

12.3.4 对于long和double型变量的特殊规则 / 327

12.3.5 原子性、可见性与有序性 / 328

12.3.6 先行发生原则 / 330

12.4 Java与线程 / 333

12.4.1 线程的实现 / 333

12.4.2 Java线程调度 / 337

12.4.3 状态转换 / 339

12.5 本章小结 / 341

第13章 线程安全与锁优化 / 342

13.1 概述 / 342

13.2 线程安全 / 343

13.2.1 Java语言中的线程安全 / 343

13.2.2 线程安全的实现方法 / 348

13.3 锁优化 / 356

13.3.1 自旋锁与自适应自旋 / 356

13.3.2 锁消除 / 357

13.3.3 锁粗化 / 358

13.3.4 轻量级锁 / 358

13.3.5 偏向锁 / 361

13.4 本章小结 / 362

附录A Java虚拟机家族 / 363

附录B 虚拟机字节码指令表 / 366

附录C HotSpot虚拟机主要参数表 / 372

附录D 对象查询语言（OQL）简介 / 376

附录E JDK历史版本轨迹 / 383

虽然许多人倾向用Overlays作为解决跨主机容器网络的实现方法，但是如果您想根据您的环境做出正确的网络选型，容器网络的功能和类型差异还是很大的，值得更深入的理解。 有些类型的网络是容器引擎不可知的，有些类型的网络被锁定到特定的平台供应商或引擎。 一些类型主要关注组网的简单性，另一些类型可能关注功能的广度或IPv6支持以及组播能力。 哪一个适合您取决于您的应用程序需求，性能要求，工作负载布局（私有或公共云）等。让我们回顾一下目前比较常见的容器网络。

本文主要关注当前容器网络类型的细分，包括：

?None

?Overlay

?Underlay

随着容器技术的进步与发展。 下面两种模式的网络方案经消失。

Links and Ambassadors

在使用Swarm实现多主机网络支持和编排之前，Docker从单主机网络开始，通过links促成网络连接，作为允许容器通过环境变量或/ etc / hosts文件条目发现彼此的机制，并传输容器之间的信息。 links的能力通常与 ambassador pattern 相结合，以便于跨主机连接容器，并降低被写死links的脆弱性。 这种方法的最大的问题是太静态了。 一旦创建了容器并定义了环境变量，如果相关的容器或服务移动到新的IP地址，则不可能更新这些变量的值。

Container-Mapped Networking

在这种网络模式下，一个容器重用（映射到）另一个容器的网络命名空间。这种联网模式只能用以下运行Docker容器的方式使用：-net：container：some_container_name_or_id。

这个运行命令标志告诉Docker将这个容器的进程放在已经在另一个容器中创建的网络栈中。当与第一个容器共享相同的IP和MAC地址和端口号时，新容器的进程仍然局限于自己的文件系统，进程列表和资源限制。这两个容器上的进程将能够通过loopback接口相互连接。

这种联网方式对正在运行的容器执行诊断有用，并且容器缺少必要的诊断工具（例如curl或dig）。可以创建具有必要诊断工具的临时容器并将其附加到第一容器的网络。

容器映射网络可以用于模拟pod式联网，其中多个容器共享相同的网络命名空间。诸如共享本地主机通信和共享同一IP地址的优点是容器在同一个pod中运行的概念所固有的，这是rkt容器的行为。

None

None 是比较直接的容器接收一个网络堆栈，但是缺少外部网络接口。 然而，它会接收一个loopback接口。 当使用无网络或空网络时，rkt和Docker容器项目均提供类似的行为。 这种容器网络的模式具有许多用途，包括测试容器，为稍后的网络连接分配容器，并且分配给不需要外部通信的容器。

Bridge

Linux网桥提供了主机内部网络，其中同一主机上的容器可以通信，但是分配给每个容器的IP地址不能从主机外部访问。 Bridge网络利用iptables进行NAT和端口映射，从而提供单主机网络。桥接网络是默认的Docker网络类型（即，docker0），其中虚拟网络接口对的一端连接在网桥和容器之间。

这里有一个创建流程的例子：

1.在主机上设置网桥。

2.每个容器的命名空间都在该网桥中提供。

3.容器的ethX被映射到私有网桥接口。

4.使用带有NAT的iptables来映射每个私有容器和主机的公共接口。

NAT用于提供主机之外的通信。虽然桥接网络解决端口冲突问题并为在一台主机上运行的容器提供网络隔离，但是会带来一些NAT相关的性能成本。

Host

在这种方法中，新创建的容器与主机共享其网络命名空间，提供更高的性能（接近裸机），并且消除对NAT的需要; 然而，它确实遭受端口冲突问题。 虽然容器可以访问所有主机的网络接口，但除非在特权模式下部署，容器可能不会重新配置主机的网络堆栈。

主机网络是Mesos中使用的默认类型。 换句话说，如果框架没有指定网络类型，新的网络命名空间将不会与容器相关联，而是与主机网络相关联。 有时称为本地网络，主机网络在概念上很简单，使其更容易被理解，故障排除和使用。

Overlay

Overlays使用网络隧道在主机之间传递通信。这允许容器通过从一个主机到下一个主机隧道网络子网表现得好像它们在同一台机器上;实质上是一个网络跨越多个主机。目前存在许多隧道技术，例如虚拟可扩展局域网VXLAN。

VXLAN是Docker libnetwork的首选隧道技术，其多主机网络在1.9版本中作为原生功能。随着这种能力的引入，Docker选择利用HashiCorp的Serf作为gossip协议，选择它的邻居表交换和收敛时间的效率。

对于那些需要支持其他隧道技术的需求，Flannel可能是一个选择。它支持udp，vxlan，host-gw，aws-vpc或gce。每个云提供商隧道类型为您的帐户或者VPC在提供商的路由表中创建路由。对公共云的支持对于overlay驱动尤其重要，因为overlay能比较好的解决混合云场景，并提供扩展和冗余，而无需打开公共端口。

多主机网络在启动Docker守护程序以及键值存储时需要额外的参数。某些overlay依赖于分布式键值存储。如果你正在做容器编排，你已经有一个分布式的键值存储。

overlay层侧重于跨主机通信挑战。在同一主机上连接到两个不同overlay网络的容器不能通过本地网桥彼此通信 - 它们是彼此分段的。

Underlays

底层网络驱动将主机接口（即，eth0处的物理网络接口）直接暴露给在主机上运行的容器或VM。 两个这样的底层驱动就是MACVLAN和IPVLAN。 网络工程师非常熟悉MACVLAN和IPVLAN驱动的操作和功能。 这两个网络驱动在概念上比桥接网络更简单，不需要端口映射，并且更高效。 此外，IPVLAN具有与许多网络工程师比较青睐的L3模式。 考虑到大多数公共云中的限制（或缺乏能力），当您有本地工作负载，安全问题，流量优先级或合规要求时，底层特别有用。 不同于每个VLAN需要一个网桥，底层网络允许每个子接口一个VLAN。

MACVLAN

MACVLAN允许在主机的单个物理接口后面创建多个虚拟网络接口。每个虚拟接口具有唯一的MAC和IP地址分配，有一个限制：IP地址需要在与物理接口相同的广播域。虽然许多网络工程师可能更熟悉子接口这个术语（不要与辅助接口混淆），但用于描述MACVLAN虚拟接口的说法通常是上层或下层接口。 MACVLAN网络是一种消除对LINUX网桥需要的方式，NAT和端口映射，允许您直接连接到物理接口。

MACVLAN每个容器使用唯一的MAC地址，这可能导致启用了防止MAC欺骗的这种安全策略（每个物理交换机接口仅允许一个MAC地址）的网络交换机出现问题。

容器流量被过滤掉，不能与底层主机通信，将主机和它上面运行的容器完全隔离。主机无法到达容器。容器与主机隔离。这对服务提供者或多租户场景有用，并且具有比网桥模型更好的隔离。

MACVLAN需要混杂模式; MACVLAN有四种工作模式，Docker 1.12只支持桥接模式。 MACvlan桥接模式和IPvlan L2模式在功能上等效。两种模式都允许广播和组播流量进入。这些底层协议的设计考虑了内部使用案例。您的公有云里程将有所不同，因为它们的虚拟机接口上大多数不支持混合模式。

注意事项：MACVLAN桥接模式为每个容器分配唯一的MAC地址或许是跟踪网络流量和端到端可见性的福音; 然而，对于具有512个唯一MAC地址的上限的典型网络接口卡（NIC），例如BR OADCOM，应该考虑这个上限。

IPVLAN

IPVLAN与MACVLAN类似，它创建新的虚拟网络接口并为每个IP地址分配一个唯一的IP地址。区别在于，相同的MAC地址用于主机上的所有pod和容器 - 物理接口的相同MAC地址。对这种行为的需要主要由以下事实驱动：许多交换机的通常配置的安全状态是关闭具有来自多于一个MAC地址的业务的交换机端口。

最佳运行内核是4.2或更新版本，IPVLAN可以在L2或L3模式下运行。像MACVLAN一样，IPVLAN L2模式要求分配给子接口的IP地址与物理接口在同一子网中。然而，IPvlan L3模式要求容器网络和IP地址在与父物理接口不同的子网上。

Linux主机上的802.1q配置（使用IP Link创建时）是短暂的，因此大多数运营商使用网络启动脚本来保持配置。对于运行底层驱动程序和暴露API的程序化配置VLAN的容器引擎，自动化可以对其改进。例如，当在机架交换机顶部创建新VLAN时，这些VLAN可以通过暴露的容器引擎API.ico被推入Linux主机。

MACVLAN AND IPVLAN

当在这两种底层类型之间进行选择时，请考虑是否需要网络才能看到单个容器的MAC地址。

对于地址解析协议（ARP）和广播通信，无论是底层驱动程序的L2模式，就像连接到交换机的服务器那样，通过将大量使用802.1D分组学习操作。然而，在IPVLAN L3模式中，网络堆栈在容器内处理，不允许多播或广播流量。在这个意义之上，IPVLAN L3模式会按照您期望L3路由器的行为运行。

注意，上游L3路由器需要知道使用IPvlan创建的网络。网络广告和重新分配网络仍然需要完成。今天，Docker正在尝试边界网关协议（BGP）。虽然静态路 由可以在机架交换机的顶层创建，就像goBGP项目如雨后春笋般成立作为一个容器生态友好的方式来提供对等邻居和路由交换功能。

尽管在给定主机上支持多种联网模式，但是MACVLAN和IPVLAN不能同时在相同的物理接口上使用。总之，如果你习惯于在主机上运行trunks，可以用L2模式。如果你主要关注规模，L3则具有大规模的潜力。

DIRECT ROUTING

出于同样的原因，IPVLAN L3模式被网络工程师所青睐，他们可能选择专注于在第3层解决寻址网络复杂性。这种方法受益于利用现有的网络基础设施来管理容器网络。集中在L3的容器网络解决方案使用路由协议提供连接，这可以说更容易与现有的数据中心基础设施，连接容器，VM和裸机服务器进行相互操作。此外，L3网络扩展和提供在过滤和隔离网络流量方面的细粒度控制。

CALICO就是一个这样的项目，使用BGP为每个网络分配路由 - 特别是对使用/ 32的工作负载，这允许它与现有的数据中心基础设施无缝集成，并且不需要Overlays。没有Overlays或封装带来的开销，结果是可以组建具有卓越的性能和规模的网络。容器的可路由IP地址将IP地址与端口暴露于外部世界。被培训并习惯于使用路由协议部署，诊断和操作网络的网络工程师可能发现直接路由更容易消化。然而，值得注意的是，CALICO不支持重叠的IP地址。

FAN NETWORKING

Fan网络是实现访问更多IP地址的一种方式，从一个分配的IP地址扩展到250个IP地址。 这是一种获得更多IP而不需要重叠网络的高效方法。 当在公有云中运行容器时，这种类型的网络特别有用，其中单个IP地址被分配给主机并且启动附加网络是禁止的，或者运行另一个负载均衡实例是昂贵的。

POINT-TO-POINT

点对点可能是CoreOS rkt使用的最简单的网络类型和默认网络。 默认情况下，使用NAT或IPMASQ，它将创建一个虚拟以太网对，将一个放在主机上，另一个放在容器pod中。 点到点网络利用iptables不仅为入站流量提供端口转发，而且通过loopback接口为pod中的其他容器之间的内部通信提供端口转发。

在连接性之外，需要考虑对其他网络功能和网络服务的支持。容器网络的许多模式利用NAT和端口转发或有意避免它们的使用。选择网络时，IP地址管理IPAM，组播，广播，IPv6，负载均衡，服务发现，策略，服务质量，高级过滤和性能都是需要额外考虑的。

问题是这些能力是否受到支持。即使您的runtime，编排引擎或插件支持容器网络功能，您的基础架构也可能不支持该功能。虽然一些2级公有云提供商提供对IPv6的支持，但是在顶级公有云中却缺乏对IPv6的支持，这也增加了用户对其他网络类型（例如Overlays和FAN网络）的需求。

在IPAM方面，为了提高易用性，大多数容器runtime引擎默认使用host-local为容器分配地址，因为它们已连接到网络。host-local IPAM涉及定义要选择的固定IP地址块。跨容器网络项目普遍支持动态主机配置协议（DHCP）。容器网络模型（CNM）和容器网络接口（CNI）都具有用于与IPAM系统集成的IPAM内置和插件框架 - 这是在许多现有环境中采用的关键能力。

想了解

关于“深入理解Java虚拟机的目录”这个话题的介绍，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！