精华内容
下载资源
问答
  • 解决 Windows 照片查看器无法显示此图片,因为计算机上的可用内存可能不足解决 Windows 照片查看器无法显示此图片,因为计算机上的可用内存可能不足问题问题分析解决办法一解决办法二 解决 Windows 照片查看器无法...

    解决 Windows 照片查看器无法显示此图片,因为计算机上的可用内存可能不足

    系统:Win10

    问题描述

    最近在使用 Windows 照片查看器打开一个 jpg 文件的时候异常
    Windows 照片查看器无法显示此图片,因为计算机上的可用内存可能不足。请关闭一些目前没有使用的程序或者释放部分硬盘空间(如果硬盘几乎已满),然后重试
    在这里插入图片描述

    问题分析

    这时我们按 F11 或者图片下方中间的放映幻灯片按钮,可以查看图片,说明本身是没有问题的,而且一般导致该问题的图片都是照相机拍出来的,那是因为 Windows 图片查看器软件根本识别不了照片里的颜色,一直加载一直识别不了造成内存不足报警(因为报错时间极短,不像是过大的数据量溢出,应该是图片的某些数据超出了该软件能够处理的内存地址范围造成的)

    解决办法一

    使用画图软件或者其他软件打开该图片
    而且,也可以选择用画图将该图片另存为 bmp 格式图片,就可以用 Windows 图片查看器打开了
    在这里插入图片描述

    解决办法二

    进入控制面板,查看方式用小图标,选择颜色管理
    在这里插入图片描述
    选择高级,将设备配置文件改为:Agfa 这个选项,关闭,再重新打开原来的图片,基本都能解决了
    在这里插入图片描述

    展开全文
  • 最近由于同时打开的程序比较多,Windows 7 频繁提示:计算机的内存不足,如下图:问题原因:经过一番尝试,得出一个大概的结论:当虚拟内存空间的大小小于物理内存空间的大小时,一旦程序开的太多,物理内存被占满,...

    最近由于同时打开的程序比较多,Windows 7 频繁提示:计算机的内存不足,如下图:


    问题原因:

    经过一番尝试,得出一个大概的结论:当虚拟内存空间的大小小于物理内存空间的大小时,一旦程序开的太多,物理内存被占满,就会提示计算机的内存不足。

    但它也应该提示虚拟内存不足才对,而只是提示计算机的内存不足!

    解决方法:






    如果你只有一种类型的硬盘,其实选择“自动管理所有驱动器的分页文件大小”就可以了;

    我的情况是有一块SSD的固态硬盘,和一块普通硬盘,

    所以我希望优先使用SSD的,因为SSD的速度基本和内存一样快;

    因此我将SSD的设置为自定义大小,然后其它的普通分区选择“系统管理的大小”。

    展开全文
  • 尽管 Java™ 运行时能够解决大量的内存管理问题,但对程序内存占用情况保持警惕仍然是优化机器性能、测定内存泄露的关键。Windows 上有很多工具可以监控内存的使用。但每种工具各有长短,都有特定的倾向性,常常...
     
    
    尽管 Java™ 运行时能够解决大量的内存管理问题,但对程序的内存占用情况保持警惕仍然是优化机器性能、测定内存泄露的关键。Windows 上有很多工具可以监控内存的使用。但每种工具各有长短,都有特定的倾向性,常常没有明确地定义自己测量的是什么。作者将澄清关于内存使用的一些常见误解,介绍很多有用的工具,同时还将提供何时以及如何使用它们的指南。

    Java 技术最知名的一个优点是:与其他语言如 C 程序员不同,Java 程序员不需要对令人畏惧的内存分配和释放负责。Java 运行库可以为您管理这些任务。每个实例化的对象都自动在堆中分配内存,垃圾收集程序定期收回不再使用的对象所占据的内存。但是您还不能完全撒手不管。您仍然需要监控程序的内存使用情况,因为 Java 进程的内存不仅仅包括堆中分配的对象。它还包括程序的字节码(JVM 在运行时解释执行的指令)、JIT 代码(已经为目标处理器编译过的代码)、任何本机代码和 JVM 使用的一些元数据(异常表、行号表等等)。情况更为复杂的是,某些类型的内存(如本机库)可以在进程间共享,因此确定 Java 应用程序的内存占用可能是一项非常艰巨的任务。

    有大量在 Windows 监控内存使用的工具,但不幸的是没有一种能够提供您需要的所有信息。更糟的是,这些形形色色的工具甚至没有一个公共的词汇表。但本文会助您一臂之力,文中将介绍一些最有用的、可免费获得的工具,并提供了如何使用它们的技巧。

    Windows 内存:一次旋风般的旅行

    了解本文要讨论的工具之前,需要对 Windows 如何管理内存有基本的理解。Windows 使用一种 分页请求虚拟内存系统,现在我们就来分析一下这种系统。

    虚拟地址空间

    虚拟内存的概念在上个世纪五十年代就提出了,当时是作为解决不能一次装入实际内存的程序这一复杂问题的方案提出的。在虚拟内存系统中,程序可以访问超出可用物理内存的更大的地址集合,专用内存管理程序将这些逻辑地址映射到实际地址,使用磁盘上的临时存储保存超出的部分。

    Windows 所使用的现代虚拟内存实现中,虚拟存储被组织成大小相同的单位,称为 。每个操作系统进程占用自己的 虚拟地址空间,即一组可以读写的虚拟内存页。每个页可以有三种状态:

    • 自由:还没有进程使用这部分地址空间。如果企图访问这部分空间,无论读写都会造成某种运行时失效。该操作将导致弹出一个 Windows 对话框,提示出现了访问冲突。(Java 程序不会造成这种错误,只有用支持指针的语言编写的程序才可能造成这种问题。)

    • 保留:这部分地址空间保留给进程,以供将来使用,但是在交付之前,不能访问该地址空间。很多 Java 堆在一开始处于保留状态。

    • 提交:程序可以访问的内存,得到了完全 支持,就是说已经在分页文件中分配了页帧。提交的页只有在第一次被引用时才装入主存,因此成为 请求式分页

    图 1 说明了进程地址空间中的虚拟页如何映射到内存中的物理页帧。


    图 1. 进程地址空间中的虚拟页到物理页帧的映射
    内存组织

    如果运行的是 32 位机器(如一般的 Intel 处理器),那么进程的整个虚拟地址空间就是 4GB,因为这是用 32 位所能寻址的最大地址空间。Windows 通常不会允许您访问地址空间中的所有这些内存,进程自己使用的只有不到一半,其他供 Windows 使用。这 2 GB 的私有空间部分包含了 JVM 执行程序所需要的多数内存:Java 堆、JVM 本身的 C 堆、用于程序线程的栈、保存字节码和即时编译方法的内存、本机方法所分配的内存等等。后面介绍地址空间映射时,我们将描述这些不同的部分。

    希望分配了大量连续内存区域但这些内存不马上同时使用的程序常常结合使用保留内存和提交内存。JVM 以这种方式分配 Java 堆。参数 -mx 告诉 JVM 堆有多大,但 JVM 通常不在一开始就分配所有这些内存。它 保留 -mx 所规定的大小,标记能够提交的整个地址范围。然后它仅仅提交一部分内存,这也是内存管理程序需要在实际内存和分页文件中分配页来支持它们的那一部分。以后活动数据数量增加,堆需要扩展,JVM 可以再提交多一点内存,这些内存与当前提交的部分相邻。通过这种方式,JVM 可以维护单一的、连续的堆空间,并根据需要增长(关于如何使用 JVM 堆参数请参阅 参考资料)。

    实际内存

    物理存储页组织成大小相同的单位,通常称为 页帧。操作系统有一种数据结构称为 页表,将应用程序访问的虚拟页映射到主存中的实际页帧。没有装入的页保存在磁盘上的临时分页文件中。当应用程序要访问当前不在内存中的页时,就会出现 页面错误,导致内存管理程序从分页文件中检索该页并放到主存中,这个任务称为 分页。决定将哪些页交换出去的具体算法取决于所用的 Windows 版本,可能是最近最少访问算法的一种变体。同样要注意,Windows 允许进程间共享页帧,比如 DLL 分配的页帧,常常被多个应用程序同时使用。Windows 通过将来自不同地址空间的多个虚拟页映射到同一个物理地址来实现这种机制。

    应用程序很高兴对所有这些活动一无所知。它只知道自己的虚拟地址空间。但是,如果当前在主存中的页面集(称为 驻留集)少于实际要使用的页面集(称为 工作集),应用程序的性能很快就会显著降低。(不幸的是,本文中您将看到,我们要讨论的工具常常交换使用这两个术语,尽管它们指的是完全不同的事物。)






    Task Manager 和 PerfMon

    我们首先考察两种最常见的工具:Task Manager 和 PerfMon。这两个工具都随 Windows 一起提供,因此由此起步比较容易。

    Task Manager

    Task Manager 是一种非常见的 Windows 进程监控程序。您可以通过熟悉的 Ctrl-Alt-Delete 组合键来启动它,或者右击任务栏。Processes 选项卡显示了最详细的信息,如图 2 所示。


    图 2. Task Manager 进程选项卡
    TaskManager

    图 2 中显示的列已经通过选择 View --> Select Columns 作了调整。有些列标题非常含糊,但可以在 Task Manager 帮助中找到各列的定义。和进程内存使用情况关系最密切的计数器包括:

    • Mem Usage(内存使用):在线帮助将其称为进程的工作集(尽管很多人称之为驻留集)——当前在主存中的页面集。但是这个数值包含能够和其他进程共享的页面,因此要注意避免重复计算。比方说,如果要计算共享同一个 DLL 的两个进程的总内存占用情况,不能简单地把“内存使用”值相加。

    • Peak Mem Usage(内存使用高峰值):进程启动以来 Mem Usage(内存使用)字段的最大值。

    • Page Faults(页面错误):进程启动以来要访问的页面不在主存中的总次数。

    • VM Size(虚拟内存大小):联机帮助将其称为“分配给进程私有虚拟内存总数。”更确切地说,这是进程所 提交的内存。如果进程保留内存而没有提交,那么该值就与总地址空间的大小有很大的差别。

    虽然 Windows 文档将 Mem Usage(内存使用)称为工作集,但在该上下文中,它实际上指的是很多人所说的驻留集(resident set),明白这一点很重要。您可以在 Memory Management Reference 术语表(请参阅 参考资料)中找到这些术语的定义。 工作集 更通常的含义指的是一个逻辑概念,即在某一点上为了避免分页操作,进程需要驻留在内存中的那些页面。

    PerfMon

    随 Windows 一起提供的另一种 Microsoft 工具是 PerfMon,它监控各种各样的计数器,从打印队列到电话。PerfMon 通常在系统路径中,因此可以在命令行中输入 perfmon 来启动它。这个工具的优点是以图形化的方式显示计数器,很容易看到计数器随时间的变化情况。

    请在 PerfMon 窗口上方的工具栏中单击 + 按钮,这样会打开一个对话框让您选择要监控的计数器,如图 3a 所示。计数器按照 性能对象分成不同的类别。与内存使用关系最密切的两个类是 MemoryProcess。选中计数器然后单击 Explain 按钮,就可以看到计数器的定义。说明出现在主对话框下方弹出的单独的窗口中,如图 3b 所示。


    图 3a. PerfMon 计数器窗口
    PerfMon 计数器窗口

    图 3b. 说明
    PerfMon 说明窗口

    选择感兴趣的计数器(使用 Ctrl 可以选中多行)和要监控的实例(所分析的应用程序的 Java 进程),然后单击 Add 按钮。工具立刻开始显示选择的所有计数器的值。您可以选择用报告、图表或者直方图来显示这些值。图 4 显示的是一个直方图。


    图 4. PerfMon 直方图
    PerfMon 直方图

    如果图中什么也看不到,表明您可能需要改变比例,右击图形区域,选择 Properties 然后切换到 Graph 选项卡。也可以到计数器的 Data 选项卡改变某个计数器的比例。

    要观察的计数器
    不幸的是,PerfMon 使用了与 Task Manager 不同的术语。表 1 列出了最常用的计数器,如果有的话,还给出了相应的 Task Manager 功能:


    表 1. 常用的 PerfMon 内存计数器
    计数器名 类别 说明 等价的 Task Manager 功能
    Working Set Process 驻留集,当前在实际内存中有多少页面 Mem Usage
    Private Bytes Process 分配的私有虚拟内存总数,即提交的内存 VM Size
    Virtual Bytes Process 虚拟地址空间的总体大小,包括共享页面。因为包含保留的内存,可能比前两个值大很多 --
    Page Faults / sec(每秒钟内的页面错误数) Process(进程) 每秒中出现的平均页面错误数 链接到 Page Faults(页面错误),显示页面错误总数
    Committed Bytes(提交的字节数) Memory(内存) “提交”状态的虚拟内存总字节数 --

    尝试一个例子

    您可以下载并运行我们用 C 编写的一个小程序(请参阅 下载部分),来观察 Task Manager 和 PerfMon 中显示的这些数量。该程序首先调用 Windows VirtualAlloc 保留内存,然后再提交这些内存,最后使用其中一些内存,每 4,096 个字节写入一个值,从而将页面代入工作集。如果运行该例子,并使用 Task Manager 或 PerfMon 观察,就会发现这些值的变化情况。






    网络上的有用工具

    现在已经看到了应用程序使用多少内存,还需要深入分析内存的实际内容。这一节介绍一些更加复杂的工具,讨论什么时候适用输出结果,以及如何解释这些结果。

    PrcView

    PrcView 是我们要介绍的第一个可以观察进程地址空间内容的工具(请参阅 参考资料)。该工具不仅能用于观察内存占用,还可以设置优先级和杀死进程,还有一个很有用的命令行版本,用来列出机器上所有进程的属性。但我们要介绍的如何使用它观察内存占用情况。

    启动 PrcView 会看到一个类 Task Manager 的视图,它显示了系统中的进程。如果滚动窗口并选中一个 Java 进程,屏幕就会如图 5 所示。


    图 5. 启动后的 PrcView 窗口
    PrcView 进程查看器

    右击该 Java 进程打开弹出菜单,或者从上方的菜单条中选择 Process,就可以看到该进程的一些情况,比如它拥有的线程、加载的 DLL,也可以杀死该进程或者设置其优先级。我们所关心的是考察其内存占用,打开如图 6 所示的窗口。


    图 6. 观察进程的内存
    PrcView 内存 1

    现在我们分析一下 PrcView 显示的地址空间映射的前几行。第一行表明从地址 0 开始,有一块长度为 65,536 (64K) 的内存是自由空间。这些地址什么也没有分配,也不能用于寻址。第二行说明紧跟在后面,从地址 0x00010000 起,有一个长为 8,192 字节(两个 4K 页面)的提交内存,即可以寻址并且得到分页文件中的页帧支持的内存。然后是一段自由空间,另一段提交空间,如此等等。

    碰巧的是,这些地址空间区域对您来说没有什么意义,因为它是供 Windows 使用的。描述 Windows 地址空间的 Microsoft 文档指出,这些不同的区域是为兼容 MS-DOS 保留的用户数据和代码所用的区域从 4MB 开始(请参阅 参考资料)。

    向下滚动窗口,最终会看到某些您能够清楚识别的地址空间,如图 7 所示。


    图 7. Java 堆
    PrcView 内存 2

    图 7 中高亮显示的行及其后的一行对应 Java 堆。我们给这里启动的 Java 进程 1000MB 大小的堆(使用 -mx1000m),对于该程序而言,这个堆太大了,但这样在 PrcView 映射中更加清楚。高亮显示的一行说明堆的提交部分只有 4MB,从地址 0x10180000 开始。紧随在后面的一行显示了一个很大的保留区域,这是堆中还没有提交的那一部分。在启动过程中,JVM 首先保留出完整的 1000MB 空间(从 0x10180000 到 0x4e980000 范围之内的地址都不能用),然后提交启动过程所需要的那一部分,该例中为 4MB。为了验证该值确实对应当前的堆大小,您可以用 -verbosegc JVM 选项调用该 Java 程序,可以打印出垃圾收集程序中的详细信息。从下面的 -verbosegc 输出中第二个 GC 的第二行可以看出,当前的堆大小大约是 4MB:

    >java -mx1000m -verbosegc Hello
    [ JVMST080: verbosegc is enabled ]
    [ JVMST082: -verbose:gc output will be written to stderr ]
    <GC[0]: Expanded System Heap by 65536 bytes
    <GC(1): GC cycle started Wed Sep 29 16:55:44 2004
    <GC(1): freed 417928 bytes, 72% free (3057160/4192768), in 104 ms>
    <GC(1): mark: 2 ms, sweep: 0 ms, compact: 102 ms>
    <GC(1): refs: soft 0 (age >= 32), weak 0, final 2, phantom 0>
    <GC(1): moved 8205 objects, 642080 bytes, reason=4>

    -verbosegc 的输出格式取决于所用的 JVM 实现,请参阅 参考资料中关于 IBM JVM 的相关文章,或者参考供应商的文档。

    如果活动数据的数量增加,JVM 需要将堆的大小扩展到 4MB 之外,它就会提交稍微多一点的保留区域。就是说,新的区域可以从 0x10580000 开始,与已经提交的堆空间连接在一起。

    图 7 所示的 PrcView 窗口中,最下面一行的三个总数给出了进程提交的总内存,这些数据是根据第七列 Type 计算得到的。三个总数为:

    • Private:分页文件支持的提交内存。
    • Mapped:直接映射到文件系统的提交内存。
    • Image:属于可执行代码的提交内存,包括启动的执行文件和 DLL。

    到目前为止,我们只是在根据大小来了解堆在地址空间中的分配情况。为了更好的理解其他一些内存区域,如果能够观察内存的内部情形,会对您的了解很有帮助。这就要用到下面将讨论的工具 TopToBottom。

    TopToBottom

    TopToBottom 可以从 smidgeonsoft.com 免费获得(请参阅 参考资料)。该工具没有任何文档,但是为当前执行进程提供了一组完备的视图。您不仅能够按名称进程 ID 排序,还能够按起动时间排序,如果需要了解计算机上程序的启动顺序这一点可能很有用。

    图 8 所示的 TopToBottom 窗口中,进程是按创建时间排序的( View --> Sort --> Creation Time)。


    图 8. TopToBottom,进程按创建时间排序
    TopToBottom 启动窗口

    StartUp 选项卡显示了创建 Java 进程的进程、开始的时间和日期、所用的命令行以及可执行文件和当前目录的完整路径。也可以单击 Environment 选项卡显示启动时传递给该进程的所有环境变量的值。Modules 选项卡显示了 Java 进程所用的 DLL,如图 9 所示。


    图 9. TopToBottom Modules 选项卡
    TopToBottom 模块

    同样可以按照不同的方式对列表进行排序。在图 9 中,它们是按照初始化顺序排列的。如果双击其中的一行,可以看到 DLL 的详细信息:其地址和大小、编写的日期和时间、所依赖的其他 DLL 列表以及加载该 DLL 的所有运行中的进程列表。如果研究这个列表,就会发现有的 DLL 是每个运行的进程都要用到的,比如 NTDLL.DLL;有的在所有 Java 进程间共享,比如 JVM.DLL;而另有一些可能只有一个进程使用。

    通过累加各个 DLL 的大小就可以计算出进程所用 DLL 的总大小。但是得到的结果可能会造成误解,因为它并不意味着进程要消费所有这些内存占用。真正的大小取决于进程实际使用了 DLL 的哪些部分。这些部分将进入进程的工作集。虽然很明显,但还是要注意 DLL 是只读的和共享的。如果大量进程都使用一个给定的 DLL,同一时刻只有一组实际内存页保存 DLL 数据。这些实际的页面可以映射到不同的地址,进入使用它们的那些进程。Task Manager 之类的工具将工作集看作是共享和非共享页面的总和,因此很难确定使用 DLL 对内存占用的影响。模块信息是一种很有用的方式,提供了“最差情况下”由于 DLL 造成的内存占用,需要的话可以使用其他工具作更详尽地分析。

    我们关心的是内存占用情况,请单击 Memory 选项卡,图 10 显示了 Java 程序所用内存的一小部分。


    图 10. TopToBottom Memory 选项卡
    TopToBottom 内存

    显示的内容和 PrcView 类似,但是它仅仅显示了虚拟空间中的提交内存,而没有保留内存。但是它有两个优点。首先,它可以更详尽地描述页面。比如在图 10 中专门标记了 Thread 3760 栈区域,而不仅仅是一些读/写数据。它是别的其他数据区包括环境、进程参数、进程堆、线程栈和线程环境块(TEB)。其次,您可以直接在 TopToBottom 中浏览甚至搜索内存。您可以搜索文本字符串或者最多 16 字节的十六进制序列。可以将十六进制搜索限制在特定的序列中,在检索地址引用时这一点很方便。

    TopToBottom 也有快照功能,可以把进程的所有信息转储到剪贴板中。

    VADump

    VADump 是一种方便的命令行工具,属于 Microsoft ® Platform SDK 包(请参阅 参考资料)的一部分。它的目的是转储特定进程的虚拟地址空间和驻留集。使用 VADump 最简单的方法就是在命令行中输入以下命令:

    vadump 
     process_id
     

    process_id 是要分析的进程号。如果不带参数,则可以显示 VADump 完整的用法说明。我们建议您将结果通过管道保存到文件中(如 vadump 1234 > output.txt ),因为 VADump 生成的信息非常多,一屏放不下。

    输出中首先给出进程虚拟地址空间的索引:

    >vadump -p 3904
    Address: 00000000 Size: 00010000
    State Free
    Address: 00010000 Size: 00002000
    State Committed
    Protect Read/Write
    Type Private
    Address: 00012000 Size: 0000E000
    State Free
    Address: 00020000 Size: 00001000
    State Committed
    Protect Read/Write
    Type Private
    Address: 00021000 Size: 0000F000
    State Free
    Address: 00030000 Size: 00010000
    State Committed
    Protect Read/Write
    Type Private
    Address: 00040000 Size: 0003B000 RegionSize: 40000
    State Reserved
    Type Private
    ................................
    

    (为便于阅读,省略了部分行。)

    对于每个块,都可以看到下列信息:

    • Address:十六进制格式,相对于进程虚拟地址空间起始位置的偏移量。
    • Size:字节数,用十六进制表示。
    • State:自由、保留或提交。
    • Protection status:只读或/读写。
    • Type:私有(不能被其他进程访问)、映射(直接来自文件系统)或镜像(可执行代码)。

    然后列出进程使用的所有 DLL 及其大小,后面是工作集和分页文件使用的统计信息。

    目前为止,所提到的信息都可以从其他工具获得。但是通过 VADump 的 -o 选项还可以得到更有启发作用的输出结果。它可以生成当前工作集的快照(某一给定时刻实际存在于主存中的页面)。关于该选项文档没有提供多少信息,但是在确定驻留集中最重要的部分时,这是一个极其有用的工具,这样能够确定最可能的内存优化目标。通过定期记录内存快照,您还可以使用它确定是否存在内存泄漏。这种模式下,输出从虚拟地址空间中提交页面的详尽转储开始,无论这些页面是否还在主存中:

    >vadump -o -p 3904
    0x00010000 (0) PRIVATE Base 0x00010000
    0x00011000 (0) PRIVATE Base 0x00010000
    0x00020000 (0) PRIVATE Base 0x00020000
    0x00030000 (0) PRIVATE Base 0x00030000
    0x00031000 (0) Private Heap 2
    0x00032000 (0) Private Heap 2
    0x00033000 (0) Private Heap 2
    0x00034000 (0) Private Heap 2
    0x00035000 (0) Private Heap 2
    0x00036000 (0) Private Heap 2
    0x00037000 (0) Private Heap 2
    0x00038000 (0) Private Heap 2
    0x00039000 (0) Private Heap 2
    0x0003A000 (0) Private Heap 2
    0x0003B000 (0) Private Heap 2
    0x0003C000 (0) Private Heap 2
    0x0003D000 (0) Private Heap 2
    0x0003E000 (0) Private Heap 2
    0x0003F000 (0) Private Heap 2
    0x0007C000 (0) Stack for ThreadID 00000F64
    0x0007D000 (0) Stack for ThreadID 00000F64
    0x0007E000 (0) Stack for ThreadID 00000F64
    0x0007F000 (0) Stack for ThreadID 00000F64
    0x00080000 (7) UNKNOWN_MAPPED Base 0x00080000
    0x00090000 (0) PRIVATE Base 0x00090000
    0x00091000 (0) Process Heap
    0x00092000 (0) Process Heap
    0x00093000 (0) Process Heap
    ...........................
    

    滚动到这个长长的列表的最后,您会看到更有趣的信息:目前驻留主存的进程页面的页表映射清单:

    0xC0000000 > (0x00000000 : 0x003FFFFF) 132 Resident Pages
    (0x00280000 : 0x00286000) > jsig.dll
    (0x00290000 : 0x00297000) > xhpi.dll
    (0x002A0000 : 0x002AF000) > hpi.dll
    (0x003C0000 : 0x003D8000) > java.dll
    (0x003E0000 : 0x003F7000) > core.dll
    (0x00090000 : 0x00190000) > Process Heap segment 0
    (0x00190000 : 0x001A0000) > Private Heap 0 segment 0
    (0x001A0000 : 0x001B0000) > UNKNOWN Heap 1 segment 0
    (0x00380000 : 0x00390000) > Process Heap segment 0
    (0x00030000 : 0x00040000) > Private Heap 2 segment 0
    (0x00390000 : 0x003A0000) > Private Heap 3 segment 0
    (0x00040000 : 0x00080000) > Stack for thread 0
    0xC0001000 > (0x00400000 : 0x007FFFFF) 13 Resident Pages
    (0x00400000 : 0x00409000) > java.exe
    .................................................................
    

    每个映射都对应页表中的一项,组成了进程工作集另一个 4KB。但要从这些映射中发现应用程序的哪些部分使用了最多的内存仍然很困难,但幸运的是下一部分输出给出了有用的总结:

    Category Total Private Shareable Shared
    Pages KBytes KBytes KBytes KBytes
    Page Table Pages 20 80 80 0 0
    Other System 10 40 40 0 0
    Code/StaticData 1539 6156 3988 1200 968
    Heap 732 2928 2928 0 0
    Stack 9 36 36 0 0
    Teb 5 20 20 0 0
    Mapped Data 30 120 0 0 120
    Other Data 1314 5256 5252 4 0
    Total Modules 1539 6156 3988 1200 968
    Total Dynamic Data 2090 8360 8236 4 120
    Total System 30 120 120 0 0
    Grand Total Working Set 3659 14636 12344 1204 1088
    

    最有趣的两个值通常是 Heap (即 Windows 进程堆)和 Other Data。直接通过调用 Windows API 分配的内存组成了进程堆部分,Other Data 中包括 Java 堆。Grand Total Working Set 对应 Task Manager 的 Mem Usage 和 TEB 字段(进程的线程环境块所需要的内存,TEB 是一种 Windows 内部结构)。

    最后,在 VADump -o 输出的最下端总结了 DLL、堆和线程栈对工作集的相对贡献:

    Module Working Set Contributions in pages
    Total Private Shareable Shared Module
    9 2 7 0 java.exe
    85 5 0 80 ntdll.dll
    43 2 0 41 kernel32.dll
    15 2 0 13 ADVAPI32.dll
    11 2 0 9 RPCRT4.dll
    53 6 0 47 MSVCRT.dll
    253 31 222 0 jvm.dll
    6 3 3 0 jsig.dll
    7 4 3 0 xhpi.dll
    15 12 3 0 hpi.dll
    12 2 0 10 WINMM.dll
    21 2 0 19 USER32.dll
    14 2 0 12 GDI32.dll
    6 2 0 4 LPK.DLL
    10 3 0 7 USP10.dll
    24 18 6 0 java.dll
    22 16 6 0 core.dll
    18 14 4 0 zip.dll
    915 869 46 0 jitc.dll
    Heap Working Set Contributions
    6 pages from Process Heap (class 0x00000000)
    0x00090000 - 0x00190000 6 pages
    2 pages from Private Heap 0 (class 0x00001000)
    0x00190000 - 0x001A0000 2 pages
    0 pages from UNKNOWN Heap 1 (class 0x00008000)
    0x001A0000 - 0x001B0000 0 pages
    1 pages from Process Heap (class 0x00000000)
    0x00380000 - 0x00390000 1 pages
    715 pages from Private Heap 2 (class 0x00001000)
    0x00030000 - 0x00040000 15 pages
    0x008A0000 - 0x009A0000 241 pages
    0x04A60000 - 0x04C60000 450 pages
    0x054E0000 - 0x058E0000 9 pages
    1 pages from Private Heap 3 (class 0x00001000)
    0x00390000 - 0x003A0000 1 pages
    7 pages from Private Heap 4 (class 0x00001000)
    0x051A0000 - 0x051B0000 7 pages
    Stack Working Set Contributions
    4 pages from stack for thread 00000F64
    1 pages from stack for thread 00000F68
    1 pages from stack for thread 00000F78
    1 pages from stack for thread 00000F7C
    2 pages from stack for thread 00000EB0
    

    通过这种模式还可以用 VADump 获得两个或更多 Java 进程的总和内存占用情况(请参阅本文后面的 技巧和窍门)。

    Sysinternals Process Explorer

    更有用的内存分析工具来自 Sysinternals 公司(请参阅 参考资料)。其中一个工具是图形化的进程管理器,如图 11 所示,它可以作为 Task Manager 的高级代替品。


    图 11. Process Explorer 进程树
    Process Explorer

    Process Explorer 具有和 Task Manager 相同的功能。比方说,您可以得到整个系统性能的动态图形(通过 View --> System Information...),也可用类似的方式配置主进程视图中的列。在 Process --> Properties... 中,Process Explorer 提供了进程的更多信息,比如完整路径和命令行、线程、CPU 实用的动态图表和私有内存。它的用户界面非常好,如图 11 所示。它还可以观察 DLL 的信息和进程的句柄。您可以使用 Options --> Replace Task Manager 用 Process Explorer 代替默认的 Task Manager。

    Sysinternals ListDLLs

    还可以从 Sysinternals 下载两个命令行工具:ListDLLs 和 Handle。如果希望在脚本或者程序中集成某种形式的内存监控,这两个工具非常有用。

    ListDLLs 用于观察 DLL,DLL 可能造成很多内存占用。使用之前请将其添加到路径中,并使用帮助选项获得用法说明。您可以用进程 ID 或进程名调用它。下面是我们的 Java 程序调用 DLL 的列表:

    >listdlls -r 3904
    ListDLLs V2.23 - DLL lister for Win9x/NT
    Copyright (C) 1997-2000 Mark Russinovich
    http://www.sysinternals.com
    ---------------------------------------------------------------------
    java.exe pid: 3904
    Command line: java -mx1000m -verbosegc Hello
    Base Size Version Path
    0x00400000 0x9000 141.2003.0005.0022 C:/WINDOWS/system32/java.exe
    0x77f50000 0xa7000 5.01.2600.1217 C:/WINDOWS/System32/ntdll.dll
    0x77e60000 0xe6000 5.01.2600.1106 C:/WINDOWS/system32/kernel32.dll
    0x77dd0000 0x8d000 5.01.2600.1106 C:/WINDOWS/system32/ADVAPI32.dll
    0x78000000 0x87000 5.01.2600.1361 C:/WINDOWS/system32/RPCRT4.dll
    0x77c10000 0x53000 7.00.2600.1106 C:/WINDOWS/system32/MSVCRT.dll
    0x10000000 0x178000 141.2004.0003.0001 C:/Java141/jre/bin/jvm.dll
    ### Relocated from base of 0x10000000:
    0x00280000 0x6000 141.2004.0003.0001 C:/Java141/jre/bin/jsig.dll
    ### Relocated from base of 0x10000000:
    0x00290000 0x7000 141.2004.0003.0001 C:/Java141/jre/bin/xhpi.dll
    ### Relocated from base of 0x10000000:
    0x002a0000 0xf000 141.2004.0003.0001 C:/Java141/jre/bin/hpi.dll
    0x76b40000 0x2c000 5.01.2600.1106 C:/WINDOWS/system32/WINMM.dll
    0x77d40000 0x8c000 5.01.2600.1255 C:/WINDOWS/system32/USER32.dll
    0x7e090000 0x41000 5.01.2600.1346 C:/WINDOWS/system32/GDI32.dll
    0x629c0000 0x8000 5.01.2600.1126 C:/WINDOWS/system32/LPK.DLL
    0x72fa0000 0x5a000 1.409.2600.1106 C:/WINDOWS/system32/USP10.dll
    ### Relocated from base of 0x10000000:
    0x003c0000 0x18000 141.2004.0003.0001 C:/Java141/jre/bin/java.dll
    ### Relocated from base of 0x10000000:
    0x003e0000 0x17000 141.2004.0003.0001 C:/Java141/jre/bin/core.dll
    ### Relocated from base of 0x10000000:
    0x04a40000 0x12000 141.2004.0003.0001 C:/Java141/jre/bin/zip.dll
    ### Relocated from base of 0x10000000:
    0x04df0000 0x3a1000 141.2004.0003.0001 C:/Java141/jre/bin/jitc.dll
    

    也可以使用 listdlls -r java 命令,列出所有运行的 Java 进程及其使用的 DLL。

    Sysinternals Handle

    Handle 给出进程所用句柄(文件、套接字等)的列表。解压 Handle 下载文件,并将其添加到路径中,然后试着运行它。对于我们的 Java 程序,输出结果如下所示:

    >handle -p 3904
    Handle v2.2
    Copyright (C) 1997-2004 Mark Russinovich
    Sysinternals - www.sysinternals.com
    ------------------------------------------------------------------
    java.exe pid: 3904 99VXW67/cem
    c: File C:/wsappdev51/workspace/Scratch
    4c: File C:/wsappdev51/workspace/Scratch/verbosegc.out
    50: File C:/wsappdev51/workspace/Scratch/verbosegc.out
    728: File C:/WebSphere MQ/Java/lib/com.ibm.mq.jar
    72c: File C:/WebSphere MQ/Java/lib/fscontext.jar
    730: File C:/WebSphere MQ/Java/lib/connector.jar
    734: File C:/WebSphere MQ/Java/lib/jms.jar
    738: File C:/WebSphere MQ/Java/lib/jndi.jar
    73c: File C:/WebSphere MQ/Java/lib/jta.jar
    740: File C:/WebSphere MQ/Java/lib/ldap.jar
    744: File C:/WebSphere MQ/Java/lib/com.ibm.mqjms.jar
    748: File C:/WebSphere MQ/Java/lib/providerutil.jar
    74c: File C:/Java141/jre/lib/ext/oldcertpath.jar
    750: File C:/Java141/jre/lib/ext/ldapsec.jar
    754: File C:/Java141/jre/lib/ext/JawBridge.jar
    758: File C:/Java141/jre/lib/ext/jaccess.jar
    75c: File C:/Java141/jre/lib/ext/indicim.jar
    760: File C:/Java141/jre/lib/ext/ibmjceprovider.jar
    764: File C:/Java141/jre/lib/ext/ibmjcefips.jar
    768: File C:/Java141/jre/lib/ext/gskikm.jar
    794: File C:/Java141/jre/lib/charsets.jar
    798: File C:/Java141/jre/lib/xml.jar
    79c: File C:/Java141/jre/lib/server.jar
    7a0: File C:/Java141/jre/lib/ibmjssefips.jar
    7a4: File C:/Java141/jre/lib/security.jar
    7a8: File C:/Java141/jre/lib/graphics.jar
    7ac: File C:/Java141/jre/lib/core.jar
    

    可以看出我们的进程中有一个句柄,该句柄指向类路径目录和几个 JAR 文件。事实上,该进程还有更多的句柄,但默认情况下该工具仅显示引用文件的句柄。使用 -a 参数就可以显示其他句柄:

    >handle -a -p 3904
    Handle v2.2
    Copyright (C) 1997-2004 Mark Russinovich
    Sysinternals - www.sysinternals.com
    ------------------------------------------------------------------
    java.exe pid: 3904 99VXW67/cem
    c: File C:/wsappdev51/workspace/Scratch
    4c: File C:/wsappdev51/workspace/Scratch/verbosegc.out
    50: File C:/wsappdev51/workspace/Scratch/verbosegc.out
    71c: Semaphore
    720: Thread java.exe(3904): 3760
    724: Event
    728: File C:/WebSphere MQ/Java/lib/com.ibm.mq.jar
    72c: File C:/WebSphere MQ/Java/lib/fscontext.jar
    730: File C:/WebSphere MQ/Java/lib/connector.jar
    734: File C:/WebSphere MQ/Java/lib/jms.jar
    738: File C:/WebSphere MQ/Java/lib/jndi.jar
    73c: File C:/WebSphere MQ/Java/lib/jta.jar
    740: File C:/WebSphere MQ/Java/lib/ldap.jar
    744: File C:/WebSphere MQ/Java/lib/com.ibm.mqjms.jar
    748: File C:/WebSphere MQ/Java/lib/providerutil.jar
    74c: File C:/Java141/jre/lib/ext/oldcertpath.jar
    750: File C:/Java141/jre/lib/ext/ldapsec.jar
    754: File C:/Java141/jre/lib/ext/JawBridge.jar
    758: File C:/Java141/jre/lib/ext/jaccess.jar
    75c: File C:/Java141/jre/lib/ext/indicim.jar
    760: File C:/Java141/jre/lib/ext/ibmjceprovider.jar
    764: File C:/Java141/jre/lib/ext/ibmjcefips.jar
    768: File C:/Java141/jre/lib/ext/gskikm.jar
    76c: Key HKCU
    770: Semaphore
    774: Thread java.exe(3904): 3964
    778: Event
    77c: Semaphore
    780: Semaphore
    784: Thread java.exe(3904): 3960
    788: Event
    78c: Thread java.exe(3904): 3944
    790: Event
    794: File C:/Java141/jre/lib/charsets.jar
    798: File C:/Java141/jre/lib/xml.jar
    79c: File C:/Java141/jre/lib/server.jar
    7a0: File C:/Java141/jre/lib/ibmjssefips.jar
    7a4: File C:/Java141/jre/lib/security.jar
    7a8: File C:/Java141/jre/lib/graphics.jar
    7ac: File C:/Java141/jre/lib/core.jar
    7b0: Event
    7b4: Thread java.exe(3904): 3940
    7b8: Event
    7bc: Semaphore
    7c0: Directory /BaseNamedObjects
    7c4: Key HKLM/SOFTWARE/Windows NT/Drivers32
    7c8: Semaphore
    7cc: Semaphore
    7d0: Event
    7d4: Desktop /Default
    7d8: WindowStation /Windows/WindowStations/WinSta0
    7dc: Event
    7e0: WindowStation /Windows/WindowStations/WinSta0
    7e4: Event
    7e8: Section
    7ec: Port
    7f0: Directory /Windows
    7f4: Key HKLM
    7f8: Directory /KnownDll
    7fc: KeyedEvent /KernelObjects/CritSecOutOfMemoryEvent
    

    如果关心内存的使用,句柄是一个重要因素,因为每个句柄都要消耗一些空间。具体的数量取决于操作系统版本和句柄的类型。一般而言,句柄不应该对内存占用产生很大影响。只要数一数该工具输出的行数,就可以判定句柄是不是太多,或者是否还在增长。无论出现哪种情况,都值得注意,建议进行更细致的分析。






    技巧和窍门

    现在您已经操作(不是双关语,handle 还有一个含义是句柄)了我们要介绍的所有工具,下面是您单独或一起使用这些工具,改进内存监控的一些方法。

    寻找进程 ID

    为了找到应用程序的进程 ID,以便在 VADump 这样的命令行工具中使用,请在 Task Manager 中打开 Applications 选项卡右击所关心的进程。选择 Go To Process,这样就会在 Processes 选项卡中看到对应的 ID。

    确定一个 Java 进程

    是否对那些都命名为 Java 或 javaw 的进程感到困惑,希望找出您要分析的那个进程?如果从 IDE 或脚本中启动 Java 进程,要确定使用了哪一个 JVM 和发送给 Java 进程的命令行参数可能很困难。这些信息可以在 TopToBottom Startup 选项卡中找到。您可以看到调用 JVM 使用的完整命令行和进程启动的时间。

    确定大量占用句柄的进程

    是否遇到过保存文件却得到提示说文件正被另一个进程使用的情况?或者尝试关闭您认为可靠的程序而得到错误消息的情况?您可以使用 SysInternals Process Explorer 工具的 Handle Search 功能发现谁在捣乱。只要打开 Search 对话框并输入文件名即可。ProcExp 将遍历所有打开的句柄,并确定相应的进程。最终常常会发现,关闭用户界面后,编辑器或者 Web 浏览器还留下一个小的存根进程在运行。

    调查有多少内存被共享

    您可以使用 VADump 的 -o 选项获得进程当前工作集的详细视图,以及有多少是共享的。获得一个 Java 程序在系统上运行的内存转储,然后再启动另一个并转储。只要比较每个结果的 Code/StaticData 部分,就会发现“Shareable”字节变成了“Shared”,从而稍微降低了内存占用的增加。

    清理驻留集

    Windows 实现了一种“清除”进程驻留集的策略,在其看起来不再有用的时候予以清除。为了说明这一点,打开 Task Manager 的 Processes 选项框,便可以看到要监控的应用程序进程,然后最小化应用程序窗口,看看 Mem Usage 字段发生了什么变化!

    确定应用程序需要的最少内存

    对于 Windows Server 2003 和 Windows NT,Microsoft 提供了一个有趣的称为 ClearMem 的工具,如果希望进一步研究 Windows 下应用程序使用内存的情况,它可能非常有用(请参阅 参考资料)。该工具确定了实际内存的大小,分配足够的内存,很快地占用分配的内存然后将其释放。这样就增加了其他应用程序的内存占用压力,反复运行 ClearMem 的结果是迫使应用程序占用的内存数量减少到最小。






    结束语

    本文简要介绍了 Windows 如何管理内存,考察了一些最有用的免费工具,您可以用这些工具监控 Java 应用程序的内存使用。无疑您还会发现和使用其他的工具,无论从 Web 上免费下载产品还是购买商业产品,我们都希望澄清相互矛盾的术语会对您有所帮助。通常要确定您测量的目标的惟一方法就是做试验,比如我们用于示范 Task Manager 的 VM Size(虚拟内存大小)和 Mem Usage(内存使用)含义的 C 程序。

    当然这些工具只能帮助确定问题的所在,如何解决还要靠您自己。多数时候您会发现 Java 堆获取了内存的一大部分,您需要深入分析代码,确定对象引用是否超出了必要的时间。这方面有更多的工具和文章可以提供帮助, 参考资料部分给出了一些有用的链接,可以为您指出正确的方向。







    下载

    描述 名字 大小 下载方法
    A C program to demonstrate how Windows uses memory experiment.c 3KB HTTP
    关于下载方法的信息


    参考资料



    作者简介

    Emma Shepherd 的照片

    Emma Shepherd 于 2002 年 Warwick 大学获得计算机科学学士学位,毕业后就加入了 IBM。她的上一个项目是关于 Java Web 服务的,她还参与了 IBM WebSphere SDK for Web Services 和 Eclipse 插件的开发。业余时间她喜欢弹钢琴,学说塞尔维亚语。


    Martin Trotter 的照片

    Martin Trotter 毕业于 Southampton 大学,获得了电气方面的学位,几年前刚加入 IBM。从一开始他就参与了 Java 的研究,在 JVM 和 JIT 方面拥有广泛的经验,并曾领导过垃圾收集团队。其业余爱好包括制作陶器、散步、骑自行车兜风和做木工等。


    Caroline Maynard 的照片

    Caroline Maynard 从 Sussex 大学获得了数学学位,毕业后一直在 IBM 工作。她最近领导了 IBM Java ORB 的开发,对 Java 程序的内存占用很感兴趣。工作之余,她喜欢参加温彻斯特交响乐队的演出,从她的小猫爪子底下挽救小生物,陪着孩子到处旅游,有时间的时候,会列一列要做的所有工作。


    Matthew Peters 的照片

    Matthew Peters 多年前从剑桥的女王学院获得了数学学位,此后一直在 IBM 工作。最近几年从事 IBM JVM 垃圾收集程序和 JVM 性能提升的研究。

    展开全文
  • windows 应用程序2g内存限制

    千次阅读 2013-02-25 16:49:41
    我也是网上听说的,32位系统最多能分配的内存是2^32 也就是差不多4G,然后去掉系统...1. 必须有那么多内存安装(废话) 2. 操作系统要支持PAE(物理地址扩展) 就你的需要来说,XP、Win2003标准版是不可能的了,它

    我也是网上听说的,32位系统最多能分配的内存是2^32 也就是差不多4G,然后去掉系统占用的一些乱七八糟的东西,最后分给用户能控制的地址段是2G

    网上有这样一段话,仅供参考。

    32位系统使用超过4GB的物理内存也是可以的,但是有一些限制:
    1. 必须有那么多内存安装(废话)
    2. 操作系统要支持PAE(物理地址扩展)

    就你的需要来说,XP、Win2003标准版是不可能的了,它们支持PAE也只限于4GB物理内存,至少要Win2003企业版,支持32GB以上内存。

    有了操作系统的支持,32位应用程序只需要用AWE API就可以访问更多的物理内存了,AllocateUserPhysicalPages、MapUserPhysicalPages、FreeUserPhysicalPages等等。
    注意,用这种方法,分配了10GB内存,但是不能线性访问的,要分次映射(MapUserPhysicalPages)到用户的2GB地址空间中的一个小窗口,然后通过这个小窗口访问,类似DOS程序使用EMS、XMS的方法。

     

    在 64 位的 Windows 2003上运行:另一个选择是在 64 位的 Windows 操作系统上运行32 位的 Domino 服务器。这样操作可以将内核的地址空间从分配给 32 位应用程序的地址空间移出,并移入一个独立的 64 位地址空间。对于采用了 Large Address Aware 选项进行编译的Domino 7 服务器,就可以占用 32 位应用程序可用的用户地址空间上限(即4 GB)。对于未采用Large Address Aware 选项进行编译的Domino 6 服务器,缺省情况下仍然有2 GB的用户地址空间限制。关于在 64 位的 Windows平台运行32位应用程序,还有其他忠告,请参阅相关信息。

    1. 使用/3GB 参数:如上所述,这个方法是最不可行的,Lotus技术支持通常也不推荐用户使用。如果您坚持使用这个选项,请考虑加入/userva=2800 参数。因为它潜在的约束,强烈建议在应用于生产环境中之前,先在测试环境中对这个配置进行测试。


    应用层(Domino)- /3GB 参数会发挥一定作用;然而,即使启用这个内核层面的设置,32位进程还是无法使用超过2 GB的用户地址空间,除非编译时加入了 /LARGEADDRESSAWARE 参数。在编译32位可执行程序时必须指定这个参数。

    如果系统内核配置了 /3GB 参数,而在编译可执行程序(.exe)时又未使用Large Address Aware 选项,那么每个进程可寻址的用户地址空间上限依然是2GB。逻辑正好相反,这多出来的1 GB并没有还给系统内核,而是在用户地址空间中被标记成保留块。这会引发一个问题,即:1 GB的虚拟地址空间就不再可用了。因此,仅当我们考虑对进程用 /LARGEADDRESSAWARE 参数进行编译时方可使用/3GB 参数。不恰当的使用/3GB 参数非但不能解决什么问题,反而会引起更多的问题。

    展开全文
  • 测试环境: E3-1231 v3 内存16G 程序内存的上限: 32位:1.97G 64位:7.60G 达到该峰值,程序运行将无法从堆中分配内存,会报异常。
  • 如何降低Windows程序内存占用量

    千次阅读 2012-12-08 16:18:17
    *前记:这几天在优化系统的过程中,发现整个软件刚一开机就占了快200M的物理内存,在hp的工作站上面感觉都有点吃力,更别说在普通的PC上了。...在项目中对程序性能优化时,发现用SetProcessWorkingSetSize
  • 微信小程序开发- 一开始添加的视频是mp4 格式的,视频多大微信小程序就会缓存多大, 但是我如果直接在微信聊天打开视频链接就不会,缓存就很少。 比如我有个视频1G, 把它放到腾讯云对象存储,把视频链接放小...
  • openCV训练程序申请内存不足

    千次阅读 2014-11-24 13:42:58
    在用openCV训练分类器(特别是训练Adaboost类型的分类器)的时候,当样本的数量特别大的时候,就会出现申请内存不够的情况,很早以前碰到过这样的情况,最近再训练的时候又出现了这样的情况,于是在网上找了一下解决...
  • 1 获取内存使用量  获取内存使用量主要使用Psapi.h中声明的GetProcessMemoryInfo函数:  ①、在程序中添加#pragma comment(lib,”Psapi.lib”),将Psapi.lib包含进去,或者通过在工程的属性中添加Psapi.lib; ...
  • WINDOWS 单个程序配置内存上限命令。

    千次阅读 2013-02-03 15:16:34
    bcdedit /set IncreaseUserVa 4096
  • Windows系统CPU内存网络性能统计第一篇 内存

    万次阅读 多人点赞 2013-01-04 13:24:44
    最近翻出以前做过的Windows系统性能统计程序,这个程序可以统计系统中的CPU使用情况,内存使用情况以及网络流量。现在将其整理一下(共有三篇),希望对大家有所帮助。目录如下:1.《Windows系统CPU内存网络性能...
  • 转自https://blogs.msdn.microsoft.com/calvin_hsia/2010/09/27/out-of-memory-easy-ways-to-increase-the-memory-available-to-your-program/当您运行VB或C#应用程序时,即使您的 计算机有很多 内存,也可能会...
  • 监控Java应用程序Windows内存使用情况

    千次阅读 2008-08-22 11:12:00
    尽管 Java™运行时能够解决大量的内存管理问题,但对程序内存占用情况保持警惕仍然是优化机器性能、测定内存泄露的关键。Windows上有很多工具可以监控内存的使用。但每种工具各有长短,都有特定的倾向性,常常没有...
  • 1、在现场设置程序崩溃时的自动内存转储,得到dump文件  在windows 注册表如下项:  //HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/AeDebug  中提供了调试器的相关设置。  Debugger...
  • 最近工作平台保存的图片(一般由 手机上传到共作平台,工作平台另存到电脑上之后),在WIN7系统windows照片查看器无法显示此图片,图片查看器提示“因为计算机上的可用内存可能不足,请关闭一些目前没有使用的程序或...
  • Windows虚拟内存简介

    千次阅读 2017-09-30 15:13:00
    Windows系统中,系统内存本身的空间可能非常有限,但是通过虚拟内存(Virtual Memory),可以让程序可以拥有超过系统物理内存大小的可用内存空间。   顾名思义,虚拟内存是逻辑层面的划分。操作系统通过内存...
  • 参考链接:https://blog.csdn.net/testcs_dn/article/details/51553898原因: 当虚拟内存空间的大小小于物理内存空间的大小时,一旦程序开的太多,物理内存被占满,就会提示计算机的内存不足。解决方法: 修改虚拟...
  • 解决方案:网站下载了win7 64 sp1版本,重新建虚拟机,安装iso后,就可以正常的安装VMware tool了。 可能是之前下载的镜像有问题,之前下载的是win7 64那个版本的。 ...
  • 在KVM上的Windows安装Virtio驱动程序

    千次阅读 2019-11-18 17:09:41
    在KVM上的Windows安装Virtio驱动程序 2018年7月3日 Virtio驱动程序是KVM虚拟机的半虚拟化设备驱动程序。 半虚拟化驱动程序可提高机器性能,减少I / O延迟并将吞吐量提高到接近裸机水平。 对于完全虚拟化的...
  • Windows内存管理

    千次阅读 2015-03-12 17:03:33
     2.Windows内存管理  3.CPU段式内存管理  4.CPU页式内存管理   一、基本概念 1. 两个内存概念 物理内存:人尽皆知,就是插在主板上的内存条。他是固定的,内存条的容量多大,物理内存就有多大(集成显卡...
  • 首先声明: Virtual memory 和 memory swapping的概念对于UNIX等系统是两个界限很明显的概念,但是对于windows系统来说区别这两个概念无疑是没有意义的,在windows封装得复杂而又机密的虚拟内存管理技术下研究...
  • LINUX中swap与windows中虚拟内存区别

    千次阅读 2017-12-11 16:21:56
    很多朋友在安装linux的时候会遇到一个问题,那就是分区。...几乎所有安装linux的教程中都要求划分这个区域,并且其分区大小几乎都按照windows的虚拟内存建议:物理内存的2倍划分。当然了 redhat也有标准建议:
  • Windows 照片查看器无法显示此图片,因为计算机上的可用内存可能不足。请关闭一些目前没有使用的程序或者释放部分硬盘空间(如果硬盘几乎已满),然后重试。” 解决办法: 1、打开方式选择“画图”,用画图打开...
  • windows下查找java应用程序CPU与内存过高
  • windows虚拟内存管理

    千次阅读 2016-07-21 09:22:16
    在应用程序中我们无时不刻不在和内存打交道,我们总在不经意间的进行堆内存和栈内存的分配释放,所以内存是我们进行程序设计必不可少的部分。 CPU的内存管理方式 段寄存器怎么消失了? 在学习8086汇编语
  • Windows安装Android SDK与USB驱动程序

    千次阅读 2014-06-04 20:54:37
    Windows安装Android SDK与USB驱动程序 如果要进行开发,先看是选择用JDK还是Eclipse,在这里下载JDK,在这里下载Eclipse;安装好上面其中一项后(我是用的JDK),下载Android SDK Starter:android-sdk...
  • 页目录,页表2.Windows内存管理3.CPU段式内存管理4.CPU页式内存管理 一、基本概念1. 两个内存概念物理内存:人尽皆知,就是插在主板上的内存条。他是固定的,内存条的容量多大,物理内存就有多大(集成显卡系统除外...
  • 另外通过前面的《Windows内存体系(2) – 页交换文件》文章,我们可以知道,这些API分配(调拨)的内存区域最初都是位于“页交换文件”上面,当程序对该区域的某些“页面”(对虚拟内存的管理以页面为单位进行的)...
  • 一、内存为什么要对齐 虽然所有的变量都是保存在特定地址的内存中,但最好还是按照内存对齐的要求来存储。这主要出于两个方面的原因考虑: 平台原因: 不是所有的硬件平台(特别是嵌入式系统中使用的低端处理器)...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 561,822
精华内容 224,728
关键字:

windows安装程序内存不足