w1100n
This site is best viewed in Google Chrome
wiloon, 6/28/2017 14:44

http://www.cnblogs.com/chenssy/p/3746600.html TreeMap的实现是红黑树算法的实现,所以要了解TreeMap就必须对红黑树有一定的了解,其实这篇博文的名字叫做:根据红黑树的算法来分析TreeMap的实现,但是为了与Java提高篇系列博文保持一致还是叫做TreeMap比较好。通过这篇博文你可以获得如下知识点: 1、红黑树的基本概念。 2、红黑树增加节点、删除节点的实现过程。 3、红黑树左旋转、右旋转的复杂过程。 4、Java 中TreeMap是如何通过put、deleteEntry两个来实现红黑树增加、删除节点的。 我想通过这篇博文你对TreeMap一定有了更深的认识。好了,下面先简单普及红黑树知识。 一、红黑树简介 红黑树又称红-黑二叉树,它首先是一颗二叉树,它具体二叉树所有的特性。同时红黑树更是一颗自平衡的排序二叉树。 我们知道一颗基本的二叉树他们都需要满足一个基本性质–即树中的任何节点的值大于它的左子节点,且小于它的右子节点。按照这个基本性质使得树的检索效率大大提高。我们知道在生成二叉树的过程是非常容易失衡的,最坏的情况就是一边倒(只有右/左子树),这样势必会导致二叉树的检索效率大大降低(O(n)),所以为了维持二叉树的平衡,大牛们提出了各种实现的算法,如:AVL,SBT,伸展树,TREAP ,红黑树等等。 平衡二叉树必须具备如下特性:它是一棵空树或它的左右两个子树的高度差的绝对值不超过1,并且左右两个子树都是一棵平衡二叉树。也就是说该二叉树的任何一个等等子节点,其左右子树的高度都相近。 2014051700001 红黑树顾名思义就是节点是红色或者黑色的平衡二叉树,它通过颜色的约束来维持着二叉树的平衡。对于一棵有效的红黑树二叉树而言我们必须增加如下规则: 1、每个节点都只能是红色或者黑色 2、根节点是黑色 3、每个叶节点(NIL节点,空节点)是黑色的。 4、如果一个结点是红的,则它两个子节点都是黑的。也就是说在一条路径上不能出现相邻的两个红色结点。 5、从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点。 这些约束强制了红黑树的关键性质: 从根到叶子的最长的可能路径不多于最短的可能路径的两倍长。结果是这棵树大致上是平衡的。因为操作比如插入、删除和查找某个值的最坏情况时间都要求与树的高度成比例,这个在高度上的理论上限允许红黑树在最坏情况下都是高效的,而不同于普通的二叉查找树。所以红黑树它是复杂而高效的,其检索效率O(log n)。下图为一颗典型的红黑二叉树。 2014051700002 对于红黑二叉树而言它主要包括三大基本操作:左旋、右旋、着色。 2014051700004 2014051700005 左旋 右旋 (图片来自:http://www.cnblogs.com/yangecnu/p/Introduce-Red-Black-Tree.html) 本节参考文献:http://baike.baidu.com/view/133754.htm?fr=aladdin—–百度百科 注:由于本文主要是讲解Java中TreeMap,所以并没有对红黑树进行非常深入的了解和研究,如果诸位想对其进行更加深入的研究Lz提供几篇较好的博文: 1、红黑树系列集锦 2、红黑树数据结构剖析 3、红黑树 二、TreeMap数据结构 回归主角:TreeMap<<<<<< TreeMap的定义如下: public class … Continue reading

wiloon, 6/22/2017 10:11

http://blog.dyngr.com/blog/2016/09/15/java-forkjoinpool-internals/ Java 1.7 引入了一种新的并发框架—— Fork/Join Framework。 本文的主要目的是介绍 ForkJoinPool 的适用场景,实现原理,以及示例代码。 TLDR; 如果觉得文章太长的话,以下就是结论: ForkJoinPool 不是为了替代 ExecutorService,而是它的补充,在某些应用场景下性能比 ExecutorService 更好。(见 Java Tip: When to use ForkJoinPool vs ExecutorService ) ForkJoinPool 主要用于实现“分而治之”的算法,特别是分治之后递归调用的函数,例如 quick sort 等。 ForkJoinPool 最适合的是计算密集型的任务,如果存在 I/O,线程间同步,sleep() 等会造成线程长时间阻塞的情况时,最好配合使用 ManagedBlocker。 使用 首先介绍的是大家最关心的 Fork/Join Framework 的使用方法,如果对使用方法已经很熟悉的话,可以跳过这一节,直接阅读原理。 … Continue reading

wiloon, 6/15/2017 9:36

hbase.rootdir 这个目录是region server的共享目录,用来持久化HBase。URL需要是’完全正确’的,还要包含文件系统的scheme。例如,要表示hdfs中的’/hbase’目录,namenode 运行在namenode.example.org的9090端口。则需要设置为hdfs://namenode.example.org:9000/hbase。默认情况下HBase是写到/tmp的。不改这个配置,数据会在重启的时候丢失。 默认: file:///tmp/hbase-${user.name}/hbase hbase.master.port HBase的Master的端口. 默认: 60000 hbase.cluster.distributed HBase的运行模式。false是单机模式,true是分布式模式。若为false,HBase和Zookeeper会运行在同一个JVM里面。 默认: false hbase.tmp.dir 本地文件系统的临时文件夹。可以修改到一个更为持久的目录上。(/tmp会在重启时清楚) 默认:${Java.io.tmpdir}/hbase-${user.name} hbase.local.dir 作为本地存储,位于本地文件系统的路径。 默认: ${hbase.tmp.dir}/local/ hbase.master.info.port HBase Master web 界面端口. 设置为-1 意味着你不想让他运行。 0.98 版本以后默认: 16010 以前是 60010 hbase.master.info.bindAddress HBase Master web 界面绑定的端口 默认: 0.0.0.0 … Continue reading

wiloon, 6/10/2017 17:28

http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/pstack.html pstack 跟踪进程栈 此命令可显示每个进程的栈跟踪。pstack 命令必须由相应进程的属主或 root 运行。可以使用 pstack 来确定进程挂起的位置。此命令允许使用的唯一选项是要检查的进程的 PID。请参见 proc(1) 手册页。 这个命令在排查进程问题时非常有用,比如我们发现一个服务一直处于work状态(如假死状态,好似死循环),使用这个命令就能轻松定位问题所在;可以在一段时间内,多执行几次pstack,若发现代码栈总是停在同一个位置,那个位置就需要重点关注,很可能就是出问题的地方; 示例:查看bash程序进程栈: /opt/app/tdev1$ps -fe| grep bash tdev1 7013 7012 0 19:42 pts/1 00:00:00 -bash tdev1 11402 11401 0 20:31 pts/2 00:00:00 -bash tdev1 11474 11402 0 20:32 pts/2 … Continue reading

wiloon, 6/8/2017 10:55

http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/strace.html strace 跟踪进程中的系统调用 strace常用来跟踪进程执行时的系统调用和所接收的信号。 在Linux世界,进程不能直接访问硬件设备,当进程需要访问硬件设备(比如读取磁盘文件,接收网络数据等等)时,必须由用户态模式切换至内核态模式,通过系统调用访问硬件设备。strace可以跟踪到一个进程产生的系统调用,包括参数,返回值,执行消耗的时间。 6.1. 输出参数含义 每一行都是一条系统调用,等号左边是系统调用的函数名及其参数,右边是该调用的返回值。 strace 显示这些调用的参数并返回符号形式的值。strace 从内核接收信息,而且不需要以任何特殊的方式来构建内核。 $strace cat /dev/null execve(“/bin/cat”, [“cat”, “/dev/null”], [/* 22 vars */]) = 0 brk(0) = 0xab1000 access(“/etc/ld.so.nohwcap”, F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, … Continue reading

wiloon, 6/8/2017 10:35

http://www.jianshu.com/p/e134b8498413 load average:系统平均负载是CPU的Load,它所包含的信息不是CPU的使用率状况,而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息,这个数字越小越好。 1、CPU负载和CPU使用率的区别 CPU使用率:显示的是程序在运行期间实时占用的CPU百分比 CPU负载:显示的是一段时间内正在使用和等待使用CPU的平均任务数。 CPU使用率高,并不意味着负载就一定大。 举例来说:如果我有一个程序它需要一直使用CPU的运算功能,那么此时CPU的使用率可能达到100%,但是CPU的工作负载则是趋近于“1”,因为CPU仅负责一个工作嘛!如果同时执行这样的程序两个呢?CPU的使用率还是100%,但是工作负载则变成2了。所以也就是说,当CPU的工作负载越大,代表CPU必须要在不同的工作之间进行频繁的工作切换。 举例说明: 网上有篇文章举了一个有趣比喻,拿打电话来说明两者的区别,我按自己的理解阐述一下。 某公用电话亭,有一个人在打电话,四个人在等待,每人限定使用电话一分钟,若有人一分钟之内没有打完电话,只能挂掉电话去排队,等待下一轮。电话在这里就相当于CPU,而正在或等待打电话的人就相当于任务数。 在电话亭使用过程中,肯定会有人打完电话走掉,有人没有打完电话而选择重新排队,更会有新增的人在这儿排队,这个人数的变化就相当于任务数的增减。为了统计平均负载情况,我们5分钟统计一次人数,并在第1、5、15分钟的时候对统计情况取平均值,从而形成第1、5、15分钟的平均负载。 有的人拿起电话就打,一直打完1分钟,而有的人可能前三十秒在找电话号码,或者在犹豫要不要打,后三十秒才真正在打电话。如果把电话看作CPU,人数看作任务,我们就说前一个人(任务)的CPU利用率高,后一个人(任务)的CPU利用率低。 当然, CPU并不会在前三十秒工作,后三十秒歇着,只是说,有的程序涉及到大量的计算,所以CPU利用率就高,而有的程序牵涉到计算的部分很少,CPU利用率自然就低。 结论:无论CPU的利用率是高是低,跟后面有多少任务在排队没有必然关系。 2、负载为多少才算比较理想? 这个有争议,各有各的说法,个人比较赞同CPU负载小于等于0.5算是一种理想状态。 不管某个CPU的性能有多好,1秒钟能处理多少任务,我们可以认为它无关紧要,虽然事实并非如此。在评估CPU负载时,我们只以5分钟为单位为统计任务队列长度。如果每隔5分钟统计的时候,发现任务队列长度都是1,那么CPU负载就为1。假如我们只有一个单核的CPU,负载一直为1,意味着没有任务在排队,还不错。 但是我那台服务器,是双核双CPU,等于是有4个内核,每个内核的负载为1的话,总负载为4。这就是说,如果我那台服务器的CPU负载长期保持在4左右,还可以接受。 但是每个内核的负载为1,并不能算是一种理想状态!这意味着我们的CPU一直很忙,不得清闲。网上有说理想的状态是每个内核的负载为0.7左右,我比较赞同,0.7乘以内核数,得出服务器理想的CPU负载,比如我这台服务器,负载在3.0以下就可以。 3、如何来降低服务器的CPU负载? 最简单办法的是更换性能更好的服务器,不要想着仅仅提高CPU的性能,那没有用,CPU要发挥出它最好的性能还需要其它软硬件的配合。 在服务器其它方面配置合理的情况下,CPU数量和CPU核心数(即内核数)都会影响到CPU负载,因为任务最终是要分配到CPU核心去处理的。两块CPU要比一块CPU好,双核要比单核好。 因此,我们需要记住,除去CPU性能上的差异,CPU负载是基于内核数来计算的!有一个说法,“有多少内核,即有多少负载”。 4、CPU使用率到多少才算比较理想? CPU使用率长时间60-80%就认为机器有瓶颈出现。 2.load average多少是正常? 既然load是cpu计算的队列,那就应该和cpu个处理方式和cpu的个数有关系。所以我个人认为应该按系统识别的cpu个数来确定load的临界值,系统识别为8个cpu,那么load为8就是临界点,高于8就属于over load了。 3. 什么叫系统识别CPU个数? 这里涉及到cpu物理个数和超线程技术的问题。对于单处理器在满负载的情况下1.00,则双处理器的负载满额的情况是 2.00,它还有一倍的资源可以利用。从性能的角度上理解,一台主机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多,不同数量的缓存、处理器的频率等因素都可能造成性能的差异。但即便这些因素造成的实际性能稍有不同,其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则:   “有多少核心即为有多少负荷”法则: 在多核处理中,你的系统均值不应该高于处理器核心的总数量。   “核心的核心”法则: … Continue reading

wiloon, 6/5/2017 14:18

Parallel Scavenge收集器的特点是它的关注点与其他收集器不同,CMS等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间,而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量 = 运行用户代码时间 /(运行用户代码时间 + 垃圾收集时间),虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%。 停顿时间越短就越适合需要与用户交互的程序,良好的响应速度能提升用户的体验;而高吞吐量则可以最高效率地利用CPU时间,尽快地完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。 Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数及直接设置吞吐量大小的 -XX:GCTimeRatio参数。 MaxGCPauseMillis参数允许的值是一个大于0的毫秒数,收集器将尽力保证内存回收花费的时间不超过设定值。不过大家不要异想天开地认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快,GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的:系统把新生代调小一些,收集300MB新生代肯定比收集500MB快吧,这也直接导致垃圾收集发生得更频繁一些,原来10秒收集一次、每次停顿100毫秒,现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降,但吞吐量也降下来了。 GCTimeRatio参数的值应当是一个大于0小于100的整数,也就是垃圾收集时间占总时间的比率,相当于是吞吐量的倒数。如果把此参数设置为19,那允许的最大GC时间就占总时间的5%(即1 /(1+19)),默认值为99,就是允许最大1%(即1 /(1+99))的垃圾收集时间。 由于与吞吐量关系密切,Parallel Scavenge收集器也经常被称为“吞吐量优先”收集器。除上述两个参数之外,Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数,当这个参数打开之后,就不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或最大的吞吐量,这种调节方式称为GC自适应的调节策略(GC Ergonomics)。如果读者对于收集器运作原理不太了解,手工优化存在困难的时候,使用Parallel Scavenge收集器配合自适应调节策略,把内存管理的调优任务交给虚拟机去完成将是一个很不错的选择。只需要把基本的内存数据设置好(如-Xmx设置最大堆),然后使用MaxGCPauseMillis参数(更关注最大停顿时间)或GCTimeRatio参数(更关注吞吐量)给虚拟机设立一个优化目标,那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。 HotSpot VM里多个GC有部分共享的代码。有一个分代式GC框架,Serial/Serial Old/ParNew/CMS都在这个框架内;在该框架内的young collector和old collector可以任意搭配使用,所谓的“mix-and-match”。 而ParallelScavenge与G1则不在这个框架内,而是各自采用了自己特别的框架。这是因为新的GC实现时发现原本的分代式GC框架用起来不顺手。请参考官方文档的Collector Styles一段。 ParallelScavenge(PS)的young collector就如其名字所示,是并行的拷贝式收集器。本来这个young collector就是“Parallel Scavenge”所指,但因为它不兼容原本的分代式GC框架,为了凸显出它是不同的,所以它的young collector带上了PS前缀,全名变成PS Scavenge。对应的,它的old collector的名字也带上了PS前缀,叫做PS MarkSweep。 这个PS MarkSweep默认的实现实际上是一层皮,它底下真正做mark-sweep-compact工作的代码是跟分代式GC框架里的serial old(这个collector名字叫做MarkSweepCompact)是共用同一份代码的。也就是说实际上PS … Continue reading

wiloon, 6/4/2017 17:15

JMX查看当前JVM使用的GC MBean java.lang.GarbageCollector 垃圾:Garbage(名词),在系统运行过程当中所产生的一些无用的对象,这些对象占据着一定的内存空间,如果长期不被释放,可能导致OOM。 垃圾收集器:Garbage Collector(名词),负责回收垃圾对象的垃圾收集器 垃圾回收:Garbage Collect(动词),垃圾收集器工作时,对垃圾进行回收 垃圾回收线程/GC线程:垃圾收集器工作时的线程。 应用程序和GC都是一种线程,以Java的main方法为例:应用程序的线程指的是main方法的主线程,GC线程是JVM的内部线程。 在GC过程中,如果GC线程必须暂停应用程序线程(用户线程),则发生Stop the World。当然也可以允许GC线程和应用程序线程一起运行,即GC并不会暂停应用程序的线程。 串行、并行、并发:串行和并行指的是垃圾收集器工作时暂停应用程序(发生Stop the World),使用单核CPU(串行)还是多核CPU(并行)。 串行(Serial):使用单核CPU串行地进行垃圾收集 并行(Parallel):使用多CPU并行地进行垃圾收集,并行是GC线程有多个,但在运行GC线程时,用户线程是阻塞的 并发(Concurrent):垃圾收集时不会暂停应用程序线程,大部分阶段用户线程和GC线程都在运行,我们称垃圾收集器和应用程序是并发运行的。 GC暂停/Stop The World/STW:不管选择哪种GC算法,Stop-the-world都是不可避免的。Stop-the-world意味着从应用中停下来并进入到GC执行过程中去。一旦Stop-the-world发生,除了GC所需的线程外,其他线程都将停止工作,中断了的线程直到GC任务结束才继续它们的任务。GC调优通常就是为了改善stop-the-world的时间(尽量减少STW对应用程序造成的暂停时间)。 Minor GC/Majar GC/Full GC Minor GC 清理的是新生代空间,因此也叫做新生代GC Major GC 清理的是老年代的空间,因此也叫做老年代GC Full GC 清理的是整个堆:包括新生代、老年代空间 垃圾回收机制的意义   Java语言中一个显著的特点就是引入了垃圾回收机制,使c++程序员最头疼的内存管理的问题迎刃而解,它使得Java程序员在编写程序的时候不再需要考虑内存管理。由于有个垃圾回收机制,Java中的对象不再有“作用域”的概念,只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄露,有效的使用空闲的内存。 垃圾回收机制中的算法   Java语言规范没有明确地说明JVM使用哪种垃圾回收算法,但是任何一种垃圾回收算法一般要做2件基本的事情:(1)发现无用信息对象;(2)回收被无用对象占用的内存空间,使该空间可被程序再次使用 引用计数法(Reference … Continue reading

wiloon, 6/4/2017 15:11

http://ifeve.com/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3g1%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8/ G1 GC是Jdk7的新特性之一、Jdk7+版本都可以自主配置G1作为JVM GC选项;作为JVM GC算法的一次重大升级、DK7u后G1已相对稳定、且未来计划替代CMS、所以有必要深入了解下: 不同于其他的分代回收算法、G1将堆空间划分成了互相独立的区块。每块区域既有可能属于O区、也有可能是Y区,且每类区域空间可以是不连续的(对比CMS的O区和Y区都必须是连续的)。这种将O区划分成多块的理念源于:当并发后台线程寻找可回收的对象时、有些区块包含可回收的对象要比其他区块多很多。虽然在清理这些区块时G1仍然需要暂停应用线程、但可以用相对较少的时间优先回收包含垃圾最多区块。这也是为什么G1命名为Garbage First的原因:第一时间处理垃圾最多的区块。 平时工作中大多数系统都使用CMS、即使静默升级到JDK7默认仍然采用CMS、那么G1相对于CMS的区别在: G1在压缩空间方面有优势 G1通过将内存空间分成区域(Region)的方式避免内存碎片问题 Eden, Survivor, Old区不再固定、在内存使用效率上来说更灵活 G1可以通过设置预期停顿时间(Pause Time)来控制垃圾收集时间避免应用雪崩现象 G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW(stop the world)的时候做 G1会在Young GC中使用、而CMS只能在O区使用 就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合: 服务端多核CPU、JVM内存占用较大的应用(至少大于4G) 应用在运行过程中会产生大量内存碎片、需要经常压缩空间 想要更可控、可预期的GC停顿周期;防止高并发下应用雪崩现象

wiloon, 6/2/2017 13:29

System.gc: 告诉垃圾收集器打算进行垃圾收集,而垃圾收集器进不进行收集是不确定的。只是建议进行回收。 jvm有自己的gc策略,不建议手动调用。 system.gc其实是做一次full gc system.gc会暂停整个进程 system.gc一般情况下我们要禁掉,使用-XX:+DisableExplicitGC system.gc在cms gc下我们通过-XX:+ExplicitGCInvokesConcurrent来做一次稍微高效点的GC(效果比Full GC要好些) system.gc最常见的场景是RMI/NIO下的堆外内存分配等 System.runFinalization() Runs the finalization methods of any objects pending finalization. Calling this method suggests that the Java Virtual Machine expend effort toward running the finalize methods of objects that … Continue reading

wiloon, 6/2/2017 10:54

http://blog.csdn.net/qinjuning/article/details/7599796 在Java存在两种数据类型: 基本类型 和 引用类型 。 在JNI的世界里也存在类似的数据类型,与Java比较起来,其范围更具严格性,如下: 1、primitive types —-基本数据类型,如:int、 float 、char等基本类型 2、reference types—-引用类型,如:类、实例、数组。 特别需要注意:数组 —— 不管是对象数组还是基本类型数组,都作为reference types存在。 1、primitive types (基本数据类型)映射参见下表: 这些基本数据类型都是可以在Native层直接使用的 。 2、reference types (引用数据类型)映射参见下表 Java类型 Native Type 描述 注意: 1、引用数据类型则不能直接使用,需要根据JNI函数进行相应的转换后,才能使用 2、多维数组(包括二维数组)都是引用类型,需要使用 jobjectArray 类型存取其值 ; 例如:二维整型数组就是指向一位数组的数组,其声明使用方式如下: view plain copy … Continue reading

wiloon, 6/2/2017 10:35

在过去(当自定义类加载器使用不普遍的时候),类几乎是“静态的”并且很少被卸载和回收,因此类也可以被看成“永久的”。另外由于类作为JVM实现的一部分,它们不由程序来创建,因为它们也被认为是“非堆”的内存。 在JDK8之前的HotSpot虚拟机中,类的这些“永久的”数据存放在一个叫做永久代的区域。永久代一段连续的内存空间,我们在JVM启动之前可以通过设置-XX:MaxPermSize的值来控制永久代的大小,32位机器默认的永久代的大小为64M,64位的机器则为85M。永久代的垃圾回收和老年代的垃圾回收是绑定的,一旦其中一个区域被占满,这两个区都要进行垃圾回收。但是有一个明显的问题,由于我们可以通过‑XX:MaxPermSize 设置永久代的大小,一旦类的元数据超过了设定的大小,程序就会耗尽内存,并出现内存溢出错误(OOM)。 备注:在JDK7之前的HotSpot虚拟机中,纳入字符串常量池的字符串被存储在永久代中,因此导致了一系列的性能问题和内存溢出错误。 这边转自 http://www.cnblogs.com/moonandstar08/p/5001914.html 这项改动是很有必要的,因为对永久代进行调优是很困难的。永久代中的元数据可能会随着每一次Full GC发生而进行移动。并且为永久代设置空间大小也是很难确定的,因为这其中有很多影响因素,比如类的总数,常量池的大小和方法数量等。 同时,HotSpot虚拟机的每种类型的垃圾回收器都需要特殊处理永久代中的元数据。将元数据从永久代剥离出来,不仅实现了对元空间的无缝管理,还可以简化Full GC以及对以后的并发隔离类元数据等方面进行优化。 新增加的metaspace: 持久代的空间被彻底地删除了,它被一个叫元空间的区域所替代了。持久代删除了之后,很明显,JVM会忽略PermSize和MaxPermSize这两个参数,还有就是你再也看不到java.lang.OutOfMemoryError: PermGen error的异常了。 JDK 8的HotSpot JVM现在使用的是本地内存来表示类的元数据,这个区域就叫做元空间。 元空间的特点: 充分利用了Java语言规范中的好处:类及相关的元数据的生命周期与类加载器的一致。 每个加载器有专门的存储空间 只进行线性分配 不会单独回收某个类 省掉了GC扫描及压缩的时间 元空间里的对象的位置是固定的 如果GC发现某个类加载器不再存活了,会把相关的空间整个回收掉 元空间的内存分配模型 绝大多数的类元数据的空间都从本地内存中分配 用来描述类元数据的类也被删除了 分元数据分配了多个虚拟内存空间 给每个类加载器分配一个内存块的列表。块的大小取决于类加载器的类型; sun/反射/代理对应的类加载器的块会小一些 归还内存块,释放内存块列表 一旦元空间的数据被清空了,虚拟内存的空间会被回收掉 减少碎片的策略 http://www.infoq.com/cn/articles/Java-PERMGEN-Removed http://www.jianshu.com/p/7b88aa16c2f6 http://www.cnblogs.com/paddix/p/5309550.html

辽ICP备14012896