JAVA相关毕业论文外文翻译.docx

JAVA相关毕业论文外文翻译.docx

《JAVA相关毕业论文外文翻译.docx》由会员分享，可在线阅读，更多相关《JAVA相关毕业论文外文翻译.docx（11页珍藏版）》请在冰豆网上搜索。

JAVA相关毕业论文外文翻译

Java堆

Java堆，每个Java对象在其中分配，是您在编写Java应用程序时使用最频繁的内存区域。

JVM设计用于将我们与主机的特性隔离，所以将内存当作堆来考虑再正常不过了。

您一定遇到过Java堆 OutOfMemoryError ，它可能是由于对象泄漏造成的，也可能是因为堆的大小不足以存储所有数据，您也可能了解这些场景的一些调试技巧。

但是随着您的Java应用程序处理越来越多的数据和越来越多的并发负载，您可能就会遇到无法使用常规技巧进行修复的OutOfMemoryError。

在一些场景中，即使java堆未满，也会抛出错误。

当这类场景发生时，您需要理解Java运行时环境（JavaRuntimeEnvironment，JRE）内部到底发生了什么。

Java应用程序在Java运行时的虚拟化环境中运行，但是运行时本身是使用C之类的语言编写的本机程序，它也会耗用本机资源，包括本机内存。

本机内存是可用于运行时进程的内存，它与Java应用程序使用的java堆内存不同。

每种虚拟化资源（包括Java堆和Java线程）都必须存储在本机内存中，虚拟机在运行时使用的数据也是如此。

这意味着主机的硬件和操作系统施加在本机内存上的限制会影响到Java应用程序的性能。

硬件限制

本机进程遇到的许多限制都是由硬件造成的，而与操作系统没有关系。

每台计算机都有一个处理器和一些随机存取存储器（RAM），后者也称为物理内存。

处理器将数据流解释为要执行的指令，它拥有一个或多个处理单元，用于执行整数和浮点运算以及更高级的计算。

处理器具有许多寄存器 ——常快速的内存元素，用作被执行的计算的工作存储，寄存器大小决定了一次计算可使用的最大数值。

处理器通过内存总线连接到物理内存。

物理地址（处理器用于索引物理RAM的地址）的大小限制了可以寻址的内存。

例如，一个16位物理地址可以寻址0x0000到0xFFFF的内存地址，这个地址范围包括2^16=65536个惟一的内存位置。

如果每个地址引用一个存储字节，那么一个16位物理地址将允许处理器寻址64KB内存。

处理器被描述为特定数量的数据位。

这通常指的是寄存器大小，但是也存在例外，比如32位390指的是物理地址大小。

对于桌面和服务器平台，这个数字为31、32或64；对于嵌入式设备和微处理器，这个数字可能小至4。

物理地址大小可以与寄存器带宽一样大，也可以比它大或小。

如果在适当的操作系统上运行，大部分64位处理器可以运行32位程序。

操作系统和虚拟内存

如果您编写无需操作系统，直接在处理器上运行的应用程序，您可以使用处理器可以寻址的所有内存（假设连接到了足够的物理RAM）。

但是要使用多任务和硬件抽象等特性，几乎所有人都会使用某种类型的操作系统来运行他们的程序。

在Aix等多任务操作系统中，有多个程序在使用系统资源。

需要为每个程序分配物理内存区域来在其中运行。

可以设计这样一个操作系统：

每个程序直接使用物理内存，并且可以可靠地仅使用分配给它的内存。

一些嵌入式操作系统以这种方式工作，但是这在包含多个未经过集中测试的应用程序的环境中是不切实际的，因为任何程序都可能破坏其他程序或者操作系统本身的内存。

虚拟内存 允许多个进程共享物理内存，而且不会破坏彼此的数据。

在具有虚拟内存的操作系统（比如Windows、Linux和许多其他操作系统）中，每个程序都拥有自己的虚拟地址空间——一个逻辑地址区域，其大小由该系统上的地址大小规定（所以，桌面和服务器平台的虚拟地址空间为31、32或64位）。

进程的虚拟地址空间中的区域可被映射到物理内存、文件或任何其他可寻址存储。

操作系统可以将物理内存中的数据移动到未使用的交换区，以便于最充分地利用物理内存。

当程序尝试使用虚拟地址访问内存时，操作系统结合片上硬件将该虚拟地址映射到物理位置。

该位置可以是物理RAM、文件或交换区。

如果一个内存区域被移动到交换空间，那么它将在被使用之前加载回物理内存中。

在AIX上，进程是关于OS控制资源（比如文件和套接字信息）、虚拟地址空间以及至少一个执行线程的一系列信息。

虽然32位地址可以引用4GB数据，但程序不能独自使用整个4GB地址空间。

与其他操作系统一样地址空间分为多个部分，程序只能使用其中的一些部分；其余部分供操作系统使用。

与Windows和Linux相比，AIX内存模型更加复杂并且可以更加精确地进行优化。

AIX32位内存模型被分成16个256MB分段进行管理。

用户程序只能直接控制16个分段中的12个—即4GB中的3GB。

最大的限制是，本机堆和所有线程栈都保存在分段2中。

为了适应对数据需求较高的程序，AIX提供了一个大内存模型。

大内存模型允许程序员或用户附加一些共享/映射分段作为本机堆使用，通过在构建可执行程序时提供一个链接器选项或者在程序启动之前设置 LDR_CNTRL 环境变量。

要在运行时支持大内存模型，需要设置 LDR_CNTRL=MAXDATA=0xN0000000。

其中， N 位于 1 和 8 之间。

超过此范围的任何值都会造成操作系统使用默认内存模型。

在大内存模型中，本机堆从分段3开始；分段2仅用于原始（初始）线程栈。

当您使用大内存模型时，分段分配是静态的；也就是说，如果你请求4个数据分段（1GB本机堆），但是仅分配1个本机堆分段（256MB），则其他3个数据分段将不能用于内存映射。

如果您希望本机堆大于2GB，并且运行的是AIX5.1或更高版本，那么您可以使用AIX 超大内存模型。

与大内存模型类似，可以通过一个链接器选项或在运行时使用 LDR_CNTRL 环境变量来为编译时的可执行程序启用超大内存模型。

要在运行时启用超大内存模型，需置 LDR_CNTRL=MAXDATA=0xN0000000@DSA。

其中， N 位于 0 和 D 之间（如果您使用AIX5.2或更高版本），或于 1 和 A 之间（如果您使用AIX5.1）。

 N 值指定可用于本机堆的分段数量，但与大内存模型不同，这些分段可以在必要时用于映射。

通常，IBMJava运行时使用超大内存模型，除非它被 LDR_CNTRL 环境变量覆盖。

将 N 设置为 1 和 A 之间，这会使用3和C之间的分段作为本机存储。

在AIX5.2中，将 N 设置为 B 或更多会更改内存布局—它不再使用D和F作为共享库，并且允许它们用于本机存储或映射。

将 N 设置为 D 可分配最多13个分段（3.25GB）的堆。

将 N 设置为 0 可允许分段3到F用于映射—本机堆保存在分段2中。

本机内存泄漏或本机内存过度使用会造成各种问题，这取决于您是耗尽了地址空间还是用完了物理内存。

耗尽地址空间通常只发生在32位进程中—因为可以轻松地分配最大4GB地址空间。

64位进程的用户空间可以达到上千GB，并且难以用完。

如果您确实耗尽了Java进程的地址空间，则Java运行时会开始出现一些奇怪的症状，本文将在稍后讨论这些情况。

在进程地址空间大于物理内存的系统中，内存泄漏或本机内存过度使用会迫使操作系统提供一些虚拟地址空间。

访问操作系统提供的内存地址要比读取（物理内存中的）常驻地址慢很多，因为必须硬盘驱动器加载它。

如果您同时尝试使用过多RAM虚拟内存，造成数据无法存储在物理内存中，则系统挂起（thrash）—也就是花费大多数时间在交换空间与内存之间来回复制数据。

出现这种情况时，计算机和各应用程序的性能将变得很差，用户会立即觉察到出现了问题。

当JVM的Java堆被换出时，垃圾收集器的性能将变得极差，甚至会造成应用程序挂起。

如果多个Java运行时在一台机器上同时运行，则物理内存必须满足所有Java堆的需要。

Java运行时如何使用本机内存

Java运行时是一个OS进程，它受上一节所提到的硬件及操作系统限制。

运行时环境提供由一些未知用户代码驱动的功能；这使得无法预测运行时环境在各种情况下需要哪些资源。

Java应用程序在托管Java环境中采取的每一个措施都有可能影响提供该环境的运行时的资源需求。

本节讨论Java应用程序消耗本机内存的方式及原因。

Java堆和垃圾收集

Java堆是分配给对象的内存区。

IBMDeveloperKitsforJavaStandardEdition拥有一个物理堆，但一些专门的Java运行时，比如IBMWebSphereRealTime，则有多个堆。

堆可以分为多个部分，例如IBMgencon策略的 nursery 和 tenured 区。

大多数Java堆都是作为本机内存的相邻slab实现的。

控制堆大小的方法是在Java命令行中使用 -Xmx 和 -Xms 选项（mx 是堆的最大大小，ms 是初始大小）。

虽然逻辑堆（活跃使用的内存区）将根据堆中对象的数量和垃圾收集（CG）所花费的时间增大或缩小，但所使用的本机内存量仍然保持不变，并且将由 -Xmx 值（最大堆大小）决定。

内存管理器依赖作为相邻内存slab的堆，因此当堆需要扩展时无法分配更多本机内存；所有堆内存必须预先保留。

保留本机内存与分配它不同。

保留本机内存时，它不受物理内存或其他存储的支持。

虽然保留地址空间块不会耗尽物理资源，但它确实能防止内存用于其他目的。

保留从未使用的内存造成的泄漏与已分配内存的泄漏同样严重。

AIX上的IBM垃圾收集器将最大限度减少物理内存的使用，当使用的堆区域减少时，它会释放堆的备份存储。

对于大多数Java应用程序，Java堆是最大的进程地址空间使用者，因此Java启动程序使用Java堆大小来确定如何配置地址空间。

即时（Just-in-time，JIT）编译器

JIT编译器在运行时将Java字节码编译为优化的二进制码。

这将极大地改善Java运行时的速度，并允许Java应用程序的运行速度能与本机代码相提并论。

编译字节码将使用本机内存（就像静态编译器一样，比如 gcc，需要内存才能运行），但是JIT的输出（可执行代码）也可以存储在本机内存中。

包含许多经过JIT编译的方法的Java应用程序比较小的应用程序使用更多本机内存。

类和类加载器

Java应用程序由定义对象结构和方法逻辑的类组成。

它们还使用Java运行时类库中的类（比如 java.lang.String），并且可以使用第三方库。

这些类需要在它们的使用期间存储在内存中。

Java5之后的IBM实现为各类加载器分配本机内存slab，用于存储类数据。

Java5中的共享类技术将共享内存中的某个区域映射到存储只读（因此可以共享）类数据的地址空间。

当多个JVM在同一台机器上运行时，这将减少存储类数据所需的物理内存量。

共享类还可以改善JVM的启动时间。

共享类系统将固定大小的共享内存区域映射到地址空间。

可以不完全占用共享类缓存，并且其中还可以包含当前未使用的类（由其他JVM载入），因此使用共享类将比未使用共享类占用更多地址空间（但物理内存较少）。

需要重点注意，共享类不能防止类加载器取消加载—但它会造成类数据的一个子集保留在类缓存中。

加载更多类需要使用更多本机内存。

每个类加载器还有各自的本机内存开销—因此让许多类加载分别加载一个类会比让一个类加载器许多类使用更多本机内存。

记住，不仅您的应用程序类需要占用内存；框架、应用服务器、第三方库和Java运行时都包含根据需要加载且占用空间的类。

Java运行时可以卸载类以回收空间，但仅限于一些严格的条件下。

不能卸载单个类；而应卸载类加载器，其对象是加载的所有类。