jvm最小内存值,jvm内存配置参数 最小内存值

　　核心提示：原因很多，比如：1。数据量太大；无限循环；静态变量和静态方法太多；递归；无法确定它是否是被引用的对象；2.虚拟机不回收内存(内存泄漏)；说白了就是程序运行需要的内存大于虚拟机能提供的最大内存，然后内存溢出。内存溢出的问题取决于业务和部门。

　　原因有很多，比如：

　　1.数据量太大；无限循环；静态变量和静态方法太多；递归；无法确定它是否是被引用的对象；

　　2.虚拟机不回收内存(内存泄漏)；

　　说白了就是程序运行需要的内存大于虚拟机能提供的最大内存，然后内存溢出。内存溢出的问题取决于业务和系统的大小。对于一些系统，内存溢出可能并不常见，但一些系统仍然是常见的解决方案。

　　一是优化程序代码。如果业务庞大，逻辑复杂，尽量减少对全局变量的引用，让程序在用完变量时释放引用，让垃圾收集器回收释放资源。

　　二、物理解决方案是增加物理内存，然后修改为：-xms 256m-xmx 256m-xx:max new size=256m-xx:maxperm size=256m。

　　1.内存溢出的类型

　　1、Java . lang . out of memory error:perm gen space

　　JVM管理两种类型的内存，堆内存和非堆内存。堆是为开发者准备的。如上所述，它们是在JVM启动时创建的。堆不是为JVM本身保留的，它用于存储类信息。与堆不同，GC不会在运行时释放空间。如果web app使用了大量的第三方jar或者应用程序中有太多的类文件，而MaxPermSize设置刚好很小，超过它也会导致这个内存占用过多而溢出，或者tomcat在热部署时不会清理之前加载的环境，而只会将上下文更改为新部署的，会发现越来越多的非堆叠内容。

　　2、Java . lang . out of memory error:Java堆空间

　　第一种情况是补充，主要问题是出现在这种情况下。它的默认空间(-Xms)是物理内存的1/64，它的最大空间(-Xmx)是物理内存的1/4。如果剩余内存小于40%，JVM将把heap设置的值增加到XMS，如果剩余内存大于70%，JVM将把heap设置的值减少到Xms。因此，服务器的Xmx和Xms设置通常应该相同，以避免在每次GC后调整虚拟机堆的大小。假设物理内存是无限的，JVM的最大内存与操作系统有关。一般32位电脑在1.5g到3g之间，64位电脑不限。

　　注意：如果Xms超过Xmx值，或者堆最大值和非堆最大值之和超过物理内存或操作系统的最大限制，服务器将不会启动。

　　垃圾收集GC的作用

　　调用JVM GC的频率还是很高的，垃圾回收主要在两种情况下进行：

　　当应用程序线程空闲时；另一种是当java的内存堆不足时，会不断调用GC。如果连续回收不能解决内存堆不足的问题，将会报告内存不足错误。因为这个异常是由系统的运行环境决定的，所以无法预测什么时候会出现。

　　根据GC的机理，程序的运行会引起系统运行环境的变化，增加GC的触发机会。

　　为了避免这些问题，程序的设计和编写要避免垃圾对象的内存占用和GC的开销。呼叫系统。GC()只能提示JVM需要回收内存中的垃圾对象，但不一定要马上回收。

　　一个是不能解决内存资源耗尽的情况，而且还会增加GC的消耗。

　　二、JVM内存区的组成

　　浅谈java中的堆和栈

　　Java内存分为两种：一种是堆栈内存，一种是堆内存。

　　1。函数中定义的基本类型变量和对象的引用变量都分配在函数的堆栈内存中；

　　2。堆用于存储新创建的对象和数组。

　　当在函数(代码块)中定义变量时，java在堆栈中为变量分配内存空间。当超出变量的作用域时，java会自动释放为变量分配的内存空间。堆中分配的内存由java虚拟机的自动垃圾收集器管理。

　　heap的优点是可以动态分配内存大小，生存期不必提前告诉编译器，因为它是在运行时动态分配内存的。缺点是运行时动态分配内存，访问速度慢；

　　栈的优点是访问速度比堆快，缺点是栈中数据的大小和生存期必须是确定的，不灵活。

　　Java堆分为三个区域：新的、旧的和永久的。

　　GC有两个线程：

　　新创建的对象被分配到新的区域，当旧的区域也满了时，它将被GC工作线程移动到旧的区域，并且当旧的区域也满了时，它将触发GC主线程遍历堆内存中的所有对象。旧区域的大小等于Xmx减去-Xmn

　　Java堆栈存储

　　堆栈调整：参数为UseDefaultStackSize -Xss256k，表示每个线程可以申请256k的堆栈空间。

　　每个线程都有自己的堆栈。

　　3.JVM如何设置虚拟内存？

　　提示：如果JVM中98%的时间用于GC，而可用堆的大小小于2%，就会抛出这个异常消息。

　　提示：最大堆大小不应该超过可用物理内存的80%。通常，-Xms和-Xmx选项应该设置为相同的值，并且-Xmn是-Xmx值的1/4。

　　提示：JVM初始分配的内存由-Xms指定，默认为物理内存的1/64；JVM的最大分配内存由-Xmx指定，默认情况下是物理内存的1/4。

　　当默认的空闲堆内存小于40%时，JVM会将堆增加到最大限制-Xmx；当空闲堆内存超过70%时，JVM会将堆减少到最小限制-Xms。因此，服务器通常将-Xms和-Xmx设置为相等，以避免在每次GC后调整堆大小。

　　提示：假设物理内存是无限的，JVM的最大内存和操作系统有很大关系。

　　简单来说，32位处理器的可控内存空间虽然是4GB，但具体操作系统会给出一个极限。

　　这个限制一般是2GB-3GB(一般Windows系统下1.5G-2G，Linux系统下2G-3G)，但64bit以上的处理器不会有限制。

　　注意：如果Xms超过Xmx，或者堆最大值和非堆最大值之和超过物理内存或操作系统的最大限制，服务器将不会启动。

　　提示：将NewSize和MaxNewSize设置为相等，“新”的大小不能大于“旧”的一半。原因是如果旧区不够大，“主”GC会被频繁触发，性能会大大降低。

　　使用JVM -XX:PermSize设置非堆内存的初始值，默认为物理内存的1/64；

　　XX:MaxPermSize设置最大非堆内存大小，默认为物理内存的1/4。

　　解决方法：手动设置堆大小。

　　修改TOMCAT_HOME/bin/catalina.bat

　　使用catalina _ base: $ catalina _ base在“echo”上方添加以下行：

　　JAVA _ OPTS="-server-xms 800m-xmx 800m-XX:max newsize=256m "

　　四。性能检查工具的使用

　　位置内存泄漏：

　　JProfiler工具主要用于检查和跟踪系统的性能(仅由Java开发)。JProfiler可以随时监控系统的内存使用情况、垃圾回收和线程运行状态，从而监控JVM的运行状态及其性能。

　　1.应用服务器的内存长期被不合理的占用，内存经常被高水平占用，很难回收到低水平；

　　2.应用服务器极不稳定，几乎两天重启一次，有时甚至每天重启一次；

　　3.应用服务器经常做全GC(包收集)，时间比较长，大概30-40秒。当应用服务器进行全GC时，它不响应客户的事务请求，这极大地影响了系统性能。

　　因为开发环境和产品环境会有所不同，所以这个问题有时会出现在产品环境中。通常，可以使用工具来跟踪系统的内存使用情况。在某些个别情况下，可能是某个时刻使用了大量内存，导致内存不足。这时候就要继续跟踪，看接下来会不会出现下跌。

　　如果一直居高不下，一定是因为程序导致内存泄漏。

　　五、弱码的特点及解决方法

　　1.尽快释放无用对象的引用。一个好的方法是使用临时变量，这样引用变量在退出活动域后会自动设置为null，暗示垃圾收集器会收集对象以防止内存泄漏。

　　对于仍然有指针的实例，jvm不会回收这个资源，因为垃圾收集会将空对象视为垃圾，从而提高GC回收机制的效率。

　　2.在我们的程序中，不可避免地要大量使用字符串处理，应该大量使用StringBuffer而不是String。每个字符串对象必须独立地占据一个内存区域；

　　Stringstr=" aaaStringstr2=" bbbStringstr3=str str2//如果这次执行后没有再调用STR和STR2，就会放在内存中等待Java的gc回收。如果程序中这样的情况太多，就会报错上面的。使用string时建议使用StringBuffer而不是String，这样可以节省很多开销；

　　3.尽量少用静态变量，因为静态变量是全局的，GC不会回收；

　　4.避免以集中的方式创建对象，尤其是大型对象。JVM会突然需要大量内存，这必然会触发GC优化系统内存环境。显示了的声明数组空间，应用数量还是很庞大的。

　　这是我想提醒大家的一个案例：

　　使用jspsmartUpload上传文件，在运行过程中经常会出现java.outofMemoryError。用top命令看进程使用情况，用了很久发现内存比2M少，是jspsmartupload的问题。将jspsmartupload组件的源代码文件(类文件)反编译成Java文件，如梦初醒：

　　m _ total bytes=m _ request . get contentlength()；m _ binArray=new byte[m _ total bytes]；

　　变量m_totalBytes代表用户上传文件的总长度，这是一个很大的数字。如果用这么大的数来声明一个字节数组，并且给数组的每个元素分配内存空间，而m_binArray数组又不能立即释放，那么JVM的垃圾回收确实有问题，导致内存溢出。

　　为什么jspsmartUpload最后要这么做？有他的理由。根据RFC1867的http上传标准，获得文件流，但是文件流的长度未知。如果设计者想要文件的长度，他只能通过操作servletinputstream知道一次，因为没有流知道大小。只有知道文件长度，才能限制用户上传文件的长度。为了省去这个麻烦，jspsmartUpload设计器直接在内存中打开文件，判断长度是否符合标准，如果符合就写入服务器的硬盘。这个内存溢出只是我的猜测。

　　所以，在编程的时候，不要申请大空间的内存，因为web服务器的内存是有限的，尽量使用流式操作，比如

　　byte[]mFileBody=new byte[512]；BlobvField=RS . get blob( file body )；InputStreaminstream=vfield . getbinarystream()；file output stream fos=newfile output stream(save file path CFILENAME)；intbwhile((b=instream . read(mFileBody))！=-1){ fos.write(mFileBody，0，b)；} fos . close()；instream . close()；

　　5.尝试使用对象池技术提高系统性能；当一个生命周期长的对象拥有一个生命周期短的对象时，很容易造成内存泄漏。例如，当一个大的对象集有大量的业务对象时，可以考虑分块处理，然后解决一个块接着一个块释放的策略。

　　6.不要在频繁调用的方法中创建对象，尤其是避免在循环中创建对象。您可以适当地使用hashtable和vector来创建一组对象容器，然后从容器中获取这些对象，而不是在每个新的。

　　7.通常，当打开一个大文件或一次从数据库中取出太多数据时，会发生这种情况，从而导致内存不足错误。此时，需要计算最大数据量，并设置最小和最大所需内存空间值。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。