JAVA内存问题。

问题描述

JDK版本:1.6.0_19服务器:tomcat测试项目:一个简单的web程序。里面有个systemInfo.jsp页面。,调用了Runtime的totalMemory(),maxMemory(),freeMemory() 以及当前使用的内存totalMemory()-freeMemory(),CPU核数availableProcessors() 测试目的:查看JSP打出来的内存大小和任务管理器里面的JAVA进程的大小是否一样。详情: 1:以前一直没注意,这几天突然发现windows的任务管理器 里面的内存和程序真正运行的时候是不一样的。当时就迷惑了。JAVA启动后就是一个JAVA进程,我们都知道,里面包含了JAVA虚拟机还有一些其他的东西。所以任务管理器里面的内存要比我们用程序查看的时候大,因为程序里面只显示的是JAVA虚拟机的内存。这是我的理解。不知对否。 2:为什么我程序里面调用runtime.maxMemory()打印出来的最大内存数是519m(519.....K),而我设置的-Xmx是512M,好像有3M不见了。我认为可能是虚拟机不会准确的去抓去512M,只能在512M左右,不知这样理解对否。 3:让我郁闷的就是:如我前面所说,我的内存最大设置了512M,初始化内存是64M。所以totalMemory()这里的内存打出来差不多也是64M,但是任务管理器里面的JAVA内存大小是89M(程序运行5分钟),89M比我们JAVA虚拟机的内存多了25M的样子,这25M可能是TOMCAT启动后,其他东西的使用。但是和我开始想的不一样。我认为JAVA这个进程应该是512M才对,不然JAVA怎么保证他的最大内存可使用呢?如果其他程序把内存耗尽,那么这个时候JAVA虚拟机要向内存再申请的时候,就不是申请不了了吗? 4:有谁告诉一下如何用JAVA查看某个进程(不一定是JAVA的进程,比如查看QQ的进程)的内存使用情况。 5: 一个tomcat里面部署多个程序,应该就相当于一个虚拟机里面有多个程序运行吧。。这几个程序共享一个虚拟机。那么有什么办法获取一个程序的当前占用的内存吗? 问题补充:langshao 写道

解决方案

引用5: 一个tomcat里面部署多个程序,应该就相当于一个虚拟机里面有多个程序运行吧。。这几个程序共享一个虚拟机。那么有什么办法获取一个程序的当前占用的内存吗? 一个tomcat运行的时候是一个进程,不同的应用程序是由不同的线程来运行,tomcat内部把它们隔开了,但实际还是在同一个jvm,我不知有什么方法可以获得各个程序占用的内存,如果有估计也需要tomcat来提供。
解决方案二:
换个角度,单起一个应用,就可以测一个应用使用的内存了另外,如果你想测试某个部分占用内存情况,用freeMemory是不行的,可以用Sizeof这个包
解决方案三:
直接用jconsole查看啊,很简单的
解决方案四:
引用我要问的是 JAVA虚拟机最大的堆内存设置为512M,那么现在其实只用了80M,当不够的时候,虚拟机要像系统申请,这个时候如果系统没有足够的内存给JAVA虚拟机用,是否就会出错。。 jvm也是一个程序,它要向操作系统申请内存,如果操作系统的内存不足,会拒绝之,当然会出错。
解决方案五:
我觉得你不理解的主要是windows中任务管理器显示的内存。一般显示windows任务管理器显示的是真实内存,应用程序申请到的内存其实是虚拟内存,也就是如果设置了java的内存参数 -Xms512M -Xmx512M,你会看到这个进程点用了512M 的虚拟内存。windows查看虚拟内存的方法:打开任务管理器,查看,选择列,勾选“虚拟内存大小”。

时间: 2024-07-30 06:21:27

JAVA内存问题。的相关文章

android开发中的java内存泄露分析

做了较长时间的android开发了,发现其实android应用开发入门容易,但是进阶或者成为高级工程师,需要具备的基础能力还是非常高的:性能优化.内存泄露.apk瘦身.热修复等等,这些都非常的考验一个人的能力.android成长之路还很长,自己会持续的走下去.本文主要介绍android内存泄露方面的知识.其实要真的理解内存泄露,需要对JVM.java语言有一定的了解,在这个基础上就比较容易理解本文了. 一.内存泄露概念 在java中,如果一个对象没有可用价值了,但又被其他引用所指向,那么这个对象

深入理解Java内存模型(六) final

与前面介绍的锁和volatile相比较,对final域的读和写更像是普通的变量访问.对于final域,编译 器和处理器要遵守两个重排序规则: 在构造函数内对一个final域的写入,与随后把这个被构造对象的引用赋值给一个引用变量,这两个操 作之间不能重排序. 初次读一个包含final域的对象的引用,与随后初次读这个final域,这两个操作之间不能重排序. 下面,我们通过一些示例性的代码来分别说明这两个规则: public class FinalExample { int i; //普通变量 fin

深入理解Java内存模型(五) 锁

锁的释放-获取建立的happens before 关系 锁是java并发编程中最重要的同步机制.锁除了让 临界区互斥执行外,还可以让释放锁的线程向获取同一个锁的线程发送消息. 下面是锁释放-获取 的示例代码: class MonitorExample { int a = 0; public synchronized void writer() { //1 a++; //2 } //3 public synchronized void reader() { //4 int i = a; //5 -

深入理解Java内存模型(四) volatile

volatile的特性 当我们声明共享变量为volatile后,对这个变量的读/写将会很特别.理解 volatile特性的一个好方法是:把对volatile变量的单个读/写,看成是使用同一个监视器锁对这些单个 读/写操作做了同步.下面我们通过具体的示例来说明,请看下面的示例代码: class VolatileFeaturesExample { volatile long vl = 0L; //使用volatile声明64位的long型变量 public void set(long l) { vl

深入理解Java内存模型(三) 顺序一致性

数据竞争与顺序一致性保证 当程序未正确同步时,就会存在数据竞争.java内存模型规范对数 据竞争的定义如下: 在一个线程中写一个变量, 在另一个线程读同一个变量, 而且写和读没有通过同步来排序. 当代码中包含数据竞争时,程序的执行往往产生违反直觉的结果(前一章的示例正是如此).如果一 个多线程程序能正确同步,这个程序将是一个没有数据竞争的程序. JMM对正确同步的多线程程序 的内存一致性做了如下保证: 如果程序是正确同步的,程序的执行将具有顺序一致性(sequentially consisten

深入理解Java内存模型(二) 重排序

如果两个操作访问同一个变量,且这两个操作中有一个为写操作,此时这两个操作之间就存在数据依 赖性.数据依赖分下列三种类型: 上 面三种情况,只要重排序两个操作的执行顺序,程序的执行结果将会被改变. 前面提到过,编译 器和处理器可能会对操作做重排序.编译器和处理器在重排序时,会遵守数据依赖性,编译器和处理器不 会改变存在数据依赖关系的两个操作的执行顺序. 注意,这里所说的数据依赖性仅针对单个处理 器中执行的指令序列和单个线程中执行的操作,不同处理器之间和不同线程之间的数据依赖性不被编译器 和处理器考

深入理解Java内存模型(一) 基础

并发编程模型的分类 在并发编程中,我们需要处理两个关键问题:线程之间如何通信及线程之 间如何同步(这里的线程是指并发执行的活动实体).通信是指线程之间以何种机制来交换信息.在命令 式编程中,线程之间的通信机制有两种:共享内存和消息传递. 在共享内存的并发模型里,线程 之间共享程序的公共状态,线程之间通过写-读内存中的公共状态来隐式进行通信.在消息传递的并发模 型里,线程之间没有公共状态,线程之间必须通过明确的发送消息来显式进行通信. 同步是指程 序用于控制不同线程之间操作发生相对顺序的机制.在共

Java内存泄露问题分析

很多人在谈论内存泄露问题,当然对于c/c++来说,这个应该是老掉牙的问题,但是很多Java人员也越来越多得讨论这个问题,我这里写个小结,希望对大家有一定的参考价值. 内存泄漏的慨念 1.c/c++是程序员自己管理内存,Java内存是由GC自动回收的. 我虽然不是很熟悉C++,不过这个应该没有犯常识性错误吧. 2.什么是内存泄露? 内存泄露是指系统中存在无法回收的内存,有时候会造成内存不足或系统崩溃. 在C/C++中分配了内存不释放的情况就是内存泄露. 3.Java存在内存泄露 我们必须先承认这个

Java理论与实践: 修复Java内存模型,第2部分

活跃了将近三年的 JSR 133,近期发布了关于如何修复 Java 内存模型 (Java Memory Model, JMM)的公开建议.在本系列文章的 第 1 部分,专栏作 者 Brian Goetz 主要介绍最初的 JMM 中的几个严重缺陷,这些缺陷导致了一些 难度高得惊人的概念语义,这些概念原来被认为很简单.这个月,他介绍在新 JMM 中 volatile 和 final 的语义是如何变化的,这些改变使它们的语义符合 大多数开发人员的直觉.其中一些改变已经在 JDK 1.4 中出现了,另一

Java理论与实践: 修复Java内存模型,第1部分

活跃了将近三年的 JSR 133,近期发布了关于如何修复 Java 内存模型 (Java Memory Model, JMM)的公开建议.原始 JMM 中有几个严重缺陷,这导 致了一些难度高得惊人的概念语义,这些概念原来被认为很简单,如 volatile .final 以及 synchronized.在这一期的 Java 理论与实践 中,Brian Goetz 展示了如何加强 volatile 和 final 的语义,以修复 JMM.这些更改有些已经 集成在 JDK 1.4 中:而另一些将会包含