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

java 堆java 堆，每个 java 对象在其中分配，是您在编写 java 应用程序时使用最频繁的内存区域。jvm 设计用于将我们与主机的特性隔离，所以将内存当作堆来考虑再正常不过了。您一定遇到过 java 堆outofmemoryerror，它可能是由于对象泄漏造成的，也可能是因为堆的大小不足以存储所有数据，您也可能了解这些场景的一些调试技巧。但是随着您的 java 应用程序处理越来越多的数据和越来越多的并发负载，您可能就会遇到无法使用常规技巧进行修复的outofmemoryerror。在一些场景中，即使 java 堆未满，也会抛出错误。当这类场景发生时，您需要理解 java 运行时环境（java runtime environment，jre）内部到底发生了什么。java 应用程序在 java 运行时的虚拟化环境中运行，但是运行时本身是使用 c 之类的语言编写的本机程序，它也会耗用本机资源，包括本机内存。本机内存是可用于运行时进程的内存，它与 java 应用程序使用的 java 堆内存不同。每种虚拟化资源（包括 java 堆和 java 线程）都必须存储在本机内存中，虚拟机在运行时使用的数据也是如此。这意味着主机的硬件和操作系统施加在本机内存上的限制会影响到 java 应用程序的性能。硬件限制本机进程遇到的许多限制都是由硬件造成的，而与操作系统没有关系。每台计算机都有一个处理器和一些随机存取存储器（ram），后者也称为物理内存。处理器将数据流解释为要执行的指令，它拥有一个或多个处理单元，用于执行整数和浮点运算以及更高级的计算。处理器具有许多寄存器 常快速的内存元素，用作被执行的计算的工作存储，寄存器大小决定了一次计算可使用的最大数值。处理器通过内存总线连接到物理内存。物理地址（处理器用于索引物理 ram 的地址）的大小限制了可以寻址的内存。例如，一个 16 位物理地址可以寻址 0x0000 到 0xffff 的内存地址，这个地址范围包括 216 = 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 内存模型更加复杂并且可以更加精确地进行优化。aix 32 位内存模型被分成 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，并且运行的是 aix 5.1 或更高版本，那么您可以使用 aix超大内存模型。与大内存模型类似，可以通过一个链接器选项或在运行时使用ldr_cntrl环境变量来为编译时的可执行程序启用超大内存模型。要在运行时启用超大内存模型，需置ldr_cntrl=maxdata=0xn0000000dsa。其中，n位于0和d之间（如果您使用 aix 5.2 或更高版本），或于1和a之间（如果您使用 aix 5.1）。n值指定可用于本机堆的分段数量，但与大内存模型不同，这些分段可以在必要时用于映射。通常，ibm java 运行时使用超大内存模型，除非它被ldr_cntrl环境变量覆盖。将n设置为1和a之间，这会使用 3 和 c 之间的分段作为本机存储。在 aix 5.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 堆是分配给对象的内存区。ibm developer kits for java standard edition 拥有一个物理堆，但一些专门的 java 运行时，比如 ibm websphere real time，则有多个堆。堆可以分为多个部分，例如 ibm gencon 策略的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），并且可以使用第三方库。这些类需要在它们的使用期间存储在内存中。java 5 之后的 ibm 实现为各类加载器分配本机内存 slab，用于存储类数据。java 5 中的共享类技术将共享内存中的某个区域映射到存储只读（因此可以共享）类数据的地址空间。当多个 jvm 在同一台机器上运行时，这将减少存储类数据所需的物理内存量。共享类还可以改善 jvm 的启动时间。共享类系统将固定大小的共享内存区域映射到地址空间。可以不完全占用共享类缓存，并且其中还可以包含当前未使用的类（由其他 jvm 载入），因此使用共享类将比未使用共享类占用更多地址空间（但物理内存较少）。需要重点注意，共享类不能防止类加载器取消加载 但它会造成类数据的一个子集保留在类缓存中。加载更多类需要使用更多本机内存。每个类加载器还有各自的本机内存开销 因此让许多类加载分别加载一个类会比让一个类加载器许多类使用更多本机内存。记住，不仅您的应用程序类需要占用内存；框架、应用服务器、第三方库和 java 运行时都包含根据需要加载且占用空间的类。java 运行时可以卸载类以回收空间，但仅限于一些严格的条件下。不能卸载单个类；而应卸载类加载器，其对象是加载的所有类。卸载类加载器的条件仅限于：java 堆未包含到表示该类加载器的java.lang.classloader对象的引用。java 堆未包含到表示该类加载器加载的类的任何java.lang.class对象的引用。该类加载器加载的任何类的对象在 java 堆中都处于非活动状态（即未被引用）。注意，java 运行时为所有 java 应用程序创建的 3 个类默认加载器 bootstrap、extension和application 永远都无法满足这些标准；因此，通过应用程序类加载器加载的任何系统类（比如java.lang.string）或任何应用程序类都不能被释放。即使类加载器可用于收集，但运行时只将类加载器作为 gc 周期的一部分进行收集。ibm gencon gc 策略（通过-xgcpolicy:gencon命令行参数启用）仅卸载主要（tenured）收集上的类加载器。如果某个应用程序正在运行 gencon 策略并创建和释放许多类加载器，则您会发现大量本机内存在 tenured 收集期间由可收集的类加载器保存。还可以在运行时生成类，而不需要您释放它。许多 jee 应用程序使用 javaserver pages (jsp) 技术生成 web 页面。使用 jsp 为执行的各个 . jsp 页面生成类，该类的持续时间为加载它们的类加载器的生存期 通常为 web 应用程序的生存期。生成类的另一个种常用方法是使用 java 反射。使用java.lang.reflectapi 时，java 运行时必须将反射对象的方法（比如java.lang.reflect.field）连接到被反射的对象或类。这种 “访问方法” 可以使用 java native interface (jni)，它需要的设置非常少但运行缓慢，或者它可以在运行时动态地为您希望反射的各对象类型构建一个类。后一种方法设置较慢，但运行更快，因此它对于经常反射特定类的应用程序非常理想。在最初几次反射类时，java 运行时使用 jni 方法。但是在使用了几次之后，访问方法将扩展到字节访问方法中，该方法涉及构建一个类并通过一个新的类加载器来加载它。执行大量反射会造成创建许多访问程序类和类加载器。保留到反射对象的引用会造成这些类保持为活动状态并继续占用空间。由于创建字节码访问程序相当慢，因此 java 运行时可以缓存这些访问程序供稍后使用。一些应用程序和框架还缓存反射对象，因此会增加它们的本机内存占用。您可以使用系统属性控制反射访问程序行为。ibm developer kit for java 5.0 的默认扩展阀值（jni 存取器在扩展到字节码存取器中之前的使用次数）是 15。您可以通过设置sun.reflect.inflationthreshold系统属性来修改该值。您可以在 java 命令行中通过-dsun.reflect.inflationthreshold=n来设置它。如果您将inflationthreshold设置为0或更小的值，则存取器将永远不会扩展。如果您发现应用程序要创建许多sun.reflect.delegatingclassloader（用于加载字节码存取器的类加载器），则这种设置非常有用。另一种（极易造成误解的）设置也会影响反射存取器。-dsun.reflect.noinflation=true会完全禁用扩展，但它会造成字节码存取器滥用。使用-dsun.reflect.noinflation=true会增加反射类加载器占用的地址空间量，因为会创建更多的类加载器。您可以通过 javacore 转储来测量类和 jit 代码在 java 5 及以上版本中使用了多少内存。javacore 是一个纯文本文件，它包含转储发生时 java 运行时的内部状态的概述 包括关于已分配本机内存分段的信息。较新版本的 ibm developer kit for java 5 和 6 将内存使用情况归讷在 javacore 中，对于较老版本（java 5 sr10 和 java 6 sr3 之前），本文的示例代码包包括一个 perl 脚本，可以用于分配和呈现数据。如果要运行它，您需要 perl 解释器，它可以用于 aix 和其他平台。译文:the java heapthe heap of java, where every java object is allocated, is the area of memory youre most intimately connected with when writing java applications. the jvm was designed to insulate us from the host machines peculiarities, so its natural to think about the heap when you think about memory. youve no doubt encountered a java heapoutofmemoryerror caused by an object leak or by not making the heap big enough to store all your data and have probably learned a few tricks to debug these scenarios. but as your java applications handle more data and more concurrent load, you may start to experienceoutofmemoryerrors that cant be fixed using your normal bag of tricks scenarios in which the errors are thrown even though the java heap isnt full. when this happens, you need to understand what is going on inside your java runtime environment (jre).a java applications run in the java virtualized environment of the java runtime, but the runtime itself is a native program written in a language (such as c) that consumes native resources, includingnative memory. native memory is the memory available to the runtime process, as distinguished from the java heap memory that a java application uses. every virtualized resource including the java heap and java threads must be stored in native memory, along with the data used by the virtual machine as it runs. this means that the limitations on native memory imposed by the host machines hardware and operating system (os) affect what you can do with your java application.this article is one of two covering the same topic on different platforms. in both, youll learn what native memory is, how the java runtime uses it, what running out of it looks like, and how to debug a nativeoutofmemoryerror. this article covers aix and focuses on the ibm developer kit for java. though many of the restrictions that a native process experiences are imposed by the hardware, not the os. every computer has a processor and some random-access memory (ram), also known as physical memory. a processor interprets a stream of data as instructions to execute; it has one or more processing units that perform integer and floating-point arithmetic as well as more advanced computations. a processor has a number ofregisters very fast memory elements that are used as working storage for the calculations that are performed; the register size determines the largest number that a single calculation can use.the processor is connected to physical memory by the memory bus. the size of the physical address (the address used by the processor to index physical ram) limits the amount of memory that can be addressed. for example, a 16-bit physical address can address from 0x0000 to 0xffff, which gives 216 = 65536 unique memory locations. if each address references a byte of storage, a 16-bit physical address would allow a processor to address 64kb of memory.processors are described as being a certain number of bits. this normally refers to the size of the registers, although there are exceptions such as 390 31-bit where it refers to the physical address size. for desktop and server platforms, this number is 31, 32, or 64; for embedded devices and microprocessors, it can be as low as 4. the physical address size can be the same as the register width but could be larger or smaller. most 64-bit processors can run 32-bit programs when running a suitable os.operating systems and virtual memoryif you were writing applications to run directly on the processor without an os, you could use all memory that the processor can address (assuming enough physical ram is connected). but to enjoy features such as multitasking and hardware abstraction, nearly everybody uses an os of some kind to run their programs.in multitasking oss, including aix, more than one program uses system resources, including memory. each program needs to be allocated regions of physical memory to work in. its possible to design an os such that every program works directly with physical memory and is trusted to use only the memory it has been given. some embedded oss work like this, but its not practical in an environment consisting of many programs that are not tested together because any program could corrupt the memory of other programs or the os itself.virtual memoryallows multiple processes to share physical memory without being able to corrupt one anothers data. in an os with virtual memory (such as aix and many others), each program has its own virtual address space a logical region of addresses whose size is dictated by the address size on that system (so 31, 32, or 64 bits for desktop and server platforms). regions in a processs virtual address space can be mapped to physical memory, to a file, or to any other addressable storage. the os can move data held in physical memory to and from a swap area when it isnt being used, to make the best use of physical memory. when a program tries to access memory using a virtual address, the os in combination with on-chip hardware maps that virtual address to the physical location. that location could be physical ram, a file, or the swap partition. if a region of memory has been moved to swap space, then its loaded back into physical memory before being used.each instance of a native program runs as a process. on aix a process is a collection of information about os-controlled resources (such as file and socket information), a virtual address space, and at least one thread of execution.although a 32-bit address can reference 4gb of data, a program is not given the entire 4gb address space for its own use. as with other os the address space is divided up into sections, only some of which are available for a program to use; the os uses the rest. compared to windows and linux, the aix memory model is more complicated and can be tuned more precisely.the aix 32-bit memory model is divided and managed as 16 256mb segments. figure 2 shows the layout of the default 32-bit aix memory model.the user program can only directly control 12 out of 16 segments 3 out of 4gb. the most significant restriction is that the native heap and all thread stacks are held in segment 2. to accommodate programs with larger data requirements, aix provides thelarge memory model.the large memory model allows a programmer or a user to annex some of the shared/mapped segments for use as native heap either by supplying a linker option when the executable is built or by setting theldr_cntrlenvironment variable before the program is started. to enable the large memory model at run time, setldr_cntrl=maxdata=0xn0000000wherenis between1and8. any value outside this range will cause the default memory model to be used. in the large memory model, the native heap starts at segment 3; segment 2 is only used for the primordial (initial) thread stack.when you use the large memory model, the segment allocation is static; that is, if you request four data segments (for 1gb of native heap) but then only allocate one segment (256mb) of native heap, the other three data segments are unavailable for memory mapping.if you want a native heap larger than 2gb and you are running aix 5.1 or later, you can use the aixvery large memory model. the very large memory model, like the large memory model, can be enabled for an executable at compile time with a linker option or at run time using theldr_cntrlenvironment variable. to enable the very large memory model at run time, setldr_cntrl=maxdata=0xn0000000dsawherenis between0anddif you use aix 5.2 or greater, or between1andaif you are using aix 5.1. the value ofnspecifies the number of segments that can be used for native heap but, unlike in the large memory model, these segments can be used for mmapping if necessary.the ibm java runtime uses the very large memory model unless its overridden with theldr_cntrlenvironment variable.settingnbetween1andawill use the segments between 3 and c for native storage as you would expect. from aix 5.2, settingntobor higher changes the memory layout it no longer uses segments d and f for shared libraries and allows them to be used for native storage or mmapping. settingntodgives the maximum 13 segments (3.25gb) of native heap. settingnto0allows segments 3 through f to be used for mmapping the native heap is held in segment 2.a native memory leak or excessive native memory use will cause different problems depending on whether you exhaust the address space or run out of physical memory. exhausting the address space typically only happens with 32-bit processes because the maximum 4gb of address space is easy to allocate. a 64-bit process has a user space of hundreds or thousands of gigabytes and is hard to fill up even if you try. if you do exhaust the address space of a java process, then the java runtime can start to show the odd symptoms ill describe later in the article. when running on a system with more process address space than physical memory, a memory leak or excessive use of native memory will force the os to swap out some of the virtual address space. accessing a memory address that has been swapped is a lot slower than reading a resident (in physical memory) address because it must be loaded from the hard drive.if you are simultaneously trying to use so much ram-backed virtual memory that your data cannot be held in physical memory, the system will thrash that is, spend most of its time copying memory back and forth from swap space. when this happens, the performance of the computer and the individual applications will become so poor the user cant fail to notice theres a problem. when a jvms java heap is swapped out, the garbage collectors performance becomes extremely poor, to the extent that the application may appear to hang. if multiple java runtimes are in use on a single machine at the same time, the physical memory must be sufficient to fit all of the java heaps.how the java runtime uses native memorythe java runtime is an os process that is subject to the hardware and os constraints i outlined in the preceding section. runtime environments provide capabilities that are driven by some unknown user code; that makes it impossible to predict which resources the runtime environment will require in every situation. every action a java application takes inside the managed java environment can potentially affect the resource requirements of the runtime that provides that environment. this section describes how and why java applications consume native memory.the java heap and garbage collection.the java heap is the area of memory where objects are allocated. the ibm developer kits for java standard edition have one physical heap, although some specialist java runtimes such as ibm websphere real time have multiple heaps. the heap can be split up into sections such as the ibm gencon policysnurseryandtenuredareas. most java heaps are implemented as contiguous slabs of native memory.the heaps size is controlled from the java command line using the-xmxand-xmsoptions (mxis the maximum size of the heap,msis the