内存参数

基本常识 堆内存 = Eden + old + Metaspace（perm） 总内存 = 堆 + 栈 + 堆外内存 + jvm等内部使用的内存 system.gc最常见的场景是RMI/NIO下的堆外内存分配等 java -verbose:class -version：查看jvm启动时被加载的类 OutOfMemoryError 分配内存当Eden内存不够用的时候，某些情况下会尝试到Old里进行分配(比如说要分配的内存很大)，如果还是没有分配成功，于是会触发一次ygc的动作，而ygc完成之后我们会再次尝试分配，如果仍不足以分配此时的内存，那会接着做一次full gc(不过此时的soft reference不会被强制回收)，将老生代也回收一下，接着再做一次分配，仍然不够分配那会做一次强制将soft reference也回收的full gc，如果还是不能分配，那这个时候就抛出OutOfMemoryError perm用来存klass、method、constantPool等信息，klass是我们熟知的class文件在jvm里的运行时数据结构 内存相关（常用） -Xms：设置程序启动时的初始堆大小（如 -Xms4g，jvm启动时，分配最小堆大小4g） -Xmx：设置程序能获得的最大堆大小（如 -Xmx4g，jvm启动时，允许分配的最大的堆大小4g。一般设定为同一个值

JVM参数： 参数名称 含义 默认值 -Xms 初始堆大小 物理内存的1/64(<1GB) 默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制. -Xmx 最大堆大小 物理内存的1/4(<1GB) 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制 -Xmn 年轻代大小(1.4or lator) 注意 ：此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不同的。 整个堆大小=年轻代大小 + 年老代大小 + 持久代大小. 增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8 -XX:NewSize 设置年轻代大小(for 1.3/1.4) -XX:MaxNewSize 年轻代最大值(for 1.3/1.4) -XX:PermSize 设置持久代(perm gen)初始值 物理内存的1/64 -XX:MaxPermSize 设置持久代最大值 物理内存的1/4 -Xss 每个线程的堆栈大小 JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行 调整.在相同物理内存下,减小这个值能生成更多的线程

DLL注入和API Hook 第一篇 dll注入 一、什么是dll注入 　　在Windows操作系统中，运行的每一个进程都生活在自己的程序空间中，每一个进程都认为自己拥有整个机器的控制权，每个进程都认为自己拥有计算机的整个内存空间，这些假象都是操作系统创造的。理论上而言，运行在操作系统上的每一个进程之间都是互不干扰的，即每个进程都会拥有独立的地址空间。比如说进程B修改了地址为0x400000的数据，那么进程C的地址为0x400000处的数据并未随着B的修改而发生改变，并且进程C可能并不拥有地址为0x400000的内存(操作系统可能没有为进程C映射这块内存)。因此，如果某进程有一个缺陷覆盖了随机地址处的内存(这可能导致程序运行出现问题)，那么这个缺陷不会影响到其他进程所使用的内存。 　　正是由于进程的地址空间是独立的，因此我们很难编写能够与其它进程通信或控制其它进程的应用程序。 　　所谓的dll注入即是让程序A强行加载你给定的a.dll并执行你给定的a.dll里面的代码。注意，你所给定的a.dll原先并不会被程序A加载，但是当你向程序A注入了a.dll后，程序A将会执行a.dll里的代码，这个时候，你的a.dll就进入了程序A的地址空间，你就可以为所欲为了。 二、什么时候需要dll注入 　　应用程序一般会在以下情况使用dll注入技术来完成某些功能： 　　　　1.为被注入的进程添加新的

SQLite剖析之动态内存分配 SQLite通过动态内存分配来获取各种对象(例如数据库连接和SQL预处理语句)所需内存、建立数据库文件的内存Cache、保存查询结果。 1、特性 SQLite内核和它的内存分配子系统提供以下特性： （1）对内存分配失败的健壮处理。如果一个内存分配请求失败（即malloc()或realloc()返回NULL），SQLite将释放未关联的缓存页，然后重新进行分配请求。如果失败，SQLite返回SQLITE_NOMEM给应用程序。 （2）无内存泄漏。应用程序负责销毁已分配的任何对象。例如应用程序必须使用sqlite3_finalize()结束每个预处理SQL语句，使用sqlite3_close关闭每个数据库连接。只要应用程序配合，即使在内存分配失败或系统出错的情况下SQLite也绝不会泄漏内存。 （3）内存使用限制。sqlite3_soft_heap_limit64()机制可以让应用程序设置SQLite的内存使用限制。SQLite会从缓存中重用内存，而不是分配新的内存，以满足设置的限制。 （4）零分配选项。应用程序可以在启动时给SQLite提供几个大块内存的缓冲区，SQLite将用这些缓冲区作为它所有内存分配的需要，不再调用系统的malloc()和free()。 （5）应用程序提供内存分配器。应用程序在启动时可以给SQLite提供可选的内存分配器

一、常见的Java内存溢出有以下三种： 解释说明：JVM在启动的时候会自动设置JVM Heap的值，JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置。其初始空间默认是物理内存的1/64，最大空间不可超过物理内存。JVM提供-Xmn -Xms -Xmx等选项来进行设置。 出错场景：在JVM中，如果98％的时间是用于GC，且可用的Heap size不足2％时，将会出现JVM Heap溢出 解决方法：修改JVM Heap的大小。 解释说明：PermGen space是指内存的永久保存区域。这个区域主要存放Class和Meta信息，Class在被Load时就会被放入PermGen space。 出错场景：如果APP载入很多CLASS，就可能会出现PermGen space溢出。(因为sun的GC不会在程序运行时对PermGen space进行清理)常见于web服务器对JSP进行pre compile的时候 3. java.lang.StackOverflowError 即栈溢出 解释说明：JVM采用的是栈式的虚拟机，函数的调用过程都体现在堆栈和退栈上。 出错场景：通常栈的大小是1－2MB的，如果调用构造函数的 “层”太多，则会出现栈溢出 在catalina.sh文件中，找到cygwin=false，在这一行的前面加入参数，具体如下 $ vim TOMCAT

在tomcat中设置JVM参数 tomcat性能取决于内存大小 上策 ：优化代码，需要开发经验足够丰富，对开发人员要求较高 中策 ：JVM优化机制，垃圾回收机制，把不需要的内存回收，需优化catalina.sh配置文件 vim /usr/local/tomcat8/bin/catalina.sh #tomcat分配1G的内存模板 添加以下代码： JAVA OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1024m -Xmx1024m-XX:NewSize=512m -XX:MaxNewSize=512m -XX:PermSize=512m -XX:MaxPermSize=512m" 重启服务 /usr/local/tomcat8/bin/shutsown.sh /usr/local/tomcat8/bin/startup.sh 下策 ：加足够大的内存 下下策 ：写脚本，每天0点重启tomcat服务，会自动清理内存，使用比较广泛 ======================================================= 禁用tomcat AJP连接器 vim /usr/local/tomcat8/con/server.xml 将AJP连接注释掉 重启服务 /usr/local

问题说明： 公司内网环境中部署的jenkins代码发版平台突然不能访问了，查看tomcat的catalina.out日志发现报错如下： ? 1 2 3 4 5 6 [root@redmine logs] # tail -f /srv/apache-tomcat-7.0.67/logs/catalina.out ...... Exception in thread "http-bio-8080-exec-5" java.lang.OutOfMemoryError: PermGen space Exception in thread "http-bio-8080-exec-5" java.lang.OutOfMemoryError: PermGen space Exception in thread "http-bio-8080-exec-5" java.lang.OutOfMemoryError: PermGen space ...... 上面报错是由于tomcat内存溢出引起的： ? 1 2 3 [root@redmine logs] # ps -ef|grep tomcat /usr/java/jdk1 .7.0_79 /bin/java -Djava.util.logging.config. file = /srv/apache-tomcat-7 .0.67 /conf

JVM 参数的优化 JVM 是java虚拟机，是jdk最底层的东西 适当调整tomcat的运行jvm参数可以提升整体性能，和内存使用率。 JVM 内存模型 J ava ջ Java栈与每一个线程关联的，jvm在创建每个线程的时候，会分配一定的栈空间给线程使用，它主要用来存储线程执行过程中的局部变量，和方法的返回值，以及方法调用上下文，栈空间随着线程的终止而释放。 J ava 堆 Java中堆是由所有的线程共享的一块内存区域，堆用来保存各种java对象，比如数组，线程对象等。 J ava 堆的分区 Young 新生代 Eden区，两个Survivor区（一般情况）。大部分对象是在Eden区中生成，某一个时刻只有其中一个是被使用的，当Eden区满了，GC就会将存活的对象移到空闲的survivor区间中，根据jvm的策略。在经过几次垃圾收集后，任然存活于survivor的对象将被移动到oid generation区间。 (新生成的对象都在新生代，java的GC会进行垃圾回收你这个对象，但是它发现你这个内存对象还在应用，根据几次的垃圾回收，任然还有些对象没有被回收的话就给他放到老年代里，放到老年代里不一定不会被GC回收)。 Oid Generation 老年代 Oidgeneration区主要保存生命周期长的对象，一般是一些老的对象，当一些对象在Young复制转移到一定次数以后

overcommit参数需要根据不同服务来进行调整，使内存得到充分利用的同时保证系统的稳定性。比如redis服务器建议把vm.overcommit_memory设置为1. 1、vm.overcommit_ratio 和 vm.overcommit_memory内核参数 参考资料， overcommit-accounting vm.overcommit_ratio值为0到100，表示允许内核分配的内存超过实际物理内存的百分比。 vm.overcommit_memory值可以是0（default）、1、2，表示overcommit检查和分配策略。 vm.overcommit_memory=0, OVERCOMMIT_GUESS、内核做启发式计算，根据可回收的slab、swap、memory空闲空间决定是够允许分配内存空间。参考内核代码： mmap.c vm.overcommit_memory=1, OVERCOMMIT_ALWAYS表示不做overcommit检查，总是允许overcommit。 vm.overcommit_memory=2, 如果申请的内存<(total_memory * overcommit_ratio/100 + swap),那么内存申请通过。 2、redis服务器建议设置 vm.overcommit_memory=1 和 vm.overcommit_memory

JVMѧϰ 1.了解jvm内存模型 在学习jvm之前，我们先对jvm有个整体的了解，下图为java虚拟机运行时数据区，这些区域都有各自的用途，以及创建和销毁时间。 程序计数器 此区域是一块较小的内存空间，主要用途就是当前线程所执行的字节码的行号指示器。本区域为线程私有的内存，在执行native方法时，这个计数器的值为Undefined,这个区域也是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。 虚拟机栈 它的生命周期与线程相同；它描述的是java方法执行的内存模型，每个方法执行时都会创建一个栈帧用于存储方法从入栈到出栈所用到的局部变量表、操作数栈，动态链接，方法出口等。 局部变量表存放的是编译期可知的各种基本数据类型，对象引用和returnAddress类型（一条字节码指令的地址）。其中64位长度的long和double类型数据占用2个局部变量空间，其他占用一个。 本地方法栈 此区域是虚拟机使用到Native方法服务。 堆 此区域为java虚拟机所管理的内存中最大的一块。也是的有线程共享的一块区域，在虚拟机启动时创建。本区域唯一目的就是存放对象实例。 JDK1.7的堆内存模型 jdk1.7的堆内存模型分为年轻代（该区域分为三部分，Eden区和两个大小严格相同的Survivor区），老年代和永久代。 JDK1.8的堆内存模型 jdk1