IT牛人博客聚合

在这个slide中分享了Java内存管理常见的三类问题（OOM、Full GC频繁、CMS GC Promotion failed || Concurrent mode failure）的case，以及通常的解决方法。

Java内存管理问题案例分享
View more PowerPoint from BlueDavy

查看全文: http://www.udpwork.com/item/7000.html

一、ClassLoader与HotSpot

对JVM有所了解的人应该知道，类文件的格式是不能违背JVM规范的，而JVM自然会有解析类文件的工具ClassFileParser。

// hotspot/src/share/vm/classfile/classFileParser.hpp
ClassFileParser(ClassFileStream* st) { set_stream(st); }

ClassFileParser由ClassFileStream*构造，其实

// hotspot/src/share/vm/classfile/classFileStream.hpp
ClassFileStream(u1* buffe

查看全文: http://www.udpwork.com/item/6820.html

上一篇 优化屏障（Optimization barrier）第二讲

1. 大胆猜想

上一篇提到了”memory”这个关键字，为什么它能够防止-fschedule-insns优化时做代码重排呢？为什么非得给它取名为屏障呢？

其实我们可以先考究一下asm语句的用法以及Optimization barrier的原型：

// template
asm ( assembler template
: output operands /* optional */
: input operands /* optional */
: li

查看全文: http://www.udpwork.com/item/6696.html

上一篇 优化屏障（Optimization barrier）第一讲

1. gcc编译的大致过程

可以看到，gcc优化主要分两大部分:Tree优化和RTL(Register Transfer Language)优化；

前文所说的指令调度（Instruction scheduling）即为RTL优化的一部分。

2. 从RTL指令调度出发，追寻Optimization barrier的踪迹

还是从实验出发，实验代码如下：

volatile int ready;
int message[100];

void cmb (int i) {
message[i/10] = 42;
__asm__ __volatile

查看全文: http://www.udpwork.com/item/6683.html

上一篇 编译内存屏障（Compiler Memory Barrier）第一讲

1. gcc编译的大致过程

可以看到，gcc优化主要分两大部分:Tree优化和RTL(Register Transfer Language)优化；

前文所说的指令调度（Instruction scheduling）即为RTL优化的一部分。

2. 从RTL指令调度出发，追寻Compiler Memory Barrier的踪迹

还是从实验出发，实验代码如下：

volatile int ready;
int message[100];

void cmb (int i) {
message[i/10] = 42;
__asm__ __

查看全文: http://www.udpwork.com/item/6679.html

1. 编译优化导致编译器指令重排

要想理解Optimization barrier，先要理解Compiler Instruction Reorder，即编译器指令重排。

编译器指令重排是编译优化的结果，以gcc来说，它不知道为我们的代码默默做了多少事情，看看那整屏的优化选项就明了了。

本文以ubuntu下的gcc 4.4.3为实验，来逐步分析Optimization barrier的作用。

gcc的很多优化都可以造成指令重排，最常见的就是基本块重新排序（Basic block reordering）和指令调度（Instruction scheduling）。

为了解释Optimization barrier，我们只需要关注

查看全文: http://www.udpwork.com/item/6684.html

1. 编译优化导致编译器指令重排

要想理解Compiler Memory Barrier，先要理解Compiler Instruction Reorder，即编译器指令重排。

编译器指令重排是编译优化的结果，以gcc来说，它不知道为我们的代码默默做了多少事情，看看那整屏的优化选项就明了了。

本文以ubuntu下的gcc 4.4.3为实验，来逐步分析Compiler Memory Barrier的作用。

gcc的很多优化都可以造成指令重排，最常见的就是基本块重新排序（Basic block reordering）和指令调度（Instruction scheduling）。

为了解释Compiler Memory Barrie

查看全文: http://www.udpwork.com/item/6680.html

目录

前言

第一问：JMM是干吗的

第二问：JMM是什么样的

第三问：JAVA如何解决JMM面临的问题

小结

 

前言

前段时间在诚信通开源研究小组(网址http://www.goldendoc.org/)就JMM做了一次专题的学习分享，现将JMM相关的一些概念梳理分享给大家。

第一问：JMM是干吗的？

Jmm (java memory model) java内存模型，可能大家对内存分区管理相对来说比较熟悉，先简单回顾如下

ü 从多线程角度看内存，主要包括线程共享区和线程本地区

ü  从内存的数据结构看，主要包括堆，栈

ü  从内存功用看，主要包括，方法区(Method Area)，perm区（Object

查看全文: http://www.udpwork.com/item/6602.html

1. 前提基础

volatile Store 与 Store是不能被编译器重排

volatile Load 与 Load是不能被编译器重排

       关于上面这两点，可以参照JSR 133 Cookbook和Intel的ia-32-architectures第3A卷的第8章。

2. 一个事例和一个推论和一个假设

一个例子：有两个volatile变量x, y，初始值均为0，有两个处理器1和2分别对x, y做读写操作，操作顺序如下：

处理器1 ： Store x 1     |       Store y 1

处理器2 ： Load y        |        Load x

因为对于处理器1，Store x

查看全文: http://www.udpwork.com/item/6483.html

两个问题

什么是守护线程？守护线程与非守护线程有什么区别？其应用场景有哪些？

一个简单的Java程序，启动后JVM创建了哪些线程，它们的作用是什么？

熟悉上面两个问题的同学可以绕过了，不太熟的同学可以继续往下看，哈哈！

守护线程

守护线程，又叫Daemon线程，它有以下几个特点：

守护线程通常由虚拟机自己使用，比如垃圾收集器的线程；

Java程序可以把它任何创建的线程标记为守护线程；但必须在线程运行前设置；

Java初始线程(即开始于main方法的线程)是非守护线程；

只要还有任何非守护线程在运行，那么这个Java程序也在运行，即这个JVM实例还存活着；当JVM中的所有非守护线程都终止时，JVM实例将自动退出；

查看全文: http://www.udpwork.com/item/6363.html

JVM规范中一块很重要的地方就是内存的管理，JVM规范里面在功能上对JVM的内存进行了一定的划分，理解这一块内容对理解JVM的规范有一定的帮助。当然，就像许多规范一样，JVM规范虽然对内存进行了划分，但是各个JVM的实现却不一定会做这样的划分，说地确切一点是负责对应功能的内存肯定在每一个JVM的实现里面都是有的（如果没有提供参数给程序员调整的话，有些对你来说就是不可见的），但是其实现方式可以是五花八门的。另外，JVM对内存的分配和管理事实上是和Java Class文件的格式，JVM的运行机制都有密切相关，如果对这些东西有所了解，那么对内存的管理理解也会有所帮助。

先来看一张图来直观地感受下JVM规范里面是怎样对JVM的内存进行功能

查看全文: http://www.udpwork.com/item/6358.html

之前有写 基于AOP的日志调试 讨论一种跟踪Java程序的方法, 但不是很完美.后来发现了 Btrace , 由于它借助动态字节码注入技术 , 实现优雅且功能强大.

只不过, 用起来总是磕磕绊绊的, 时常为了跟踪某个问题, 却花了大把的时间调试Btrace的脚本. 为此, 我尝试将几种跟踪模式固化成脚本模板, 待用的时候去调整一下正则表达式之类的.

跟踪过程往往是假设与验证的螺旋迭代过程, 反复的用BTrace跟踪目标进程, 总有那么几次莫名其妙的不可用, 最后不得不重启目标进程. 若真是线上不能停的服务, 我想这种方式还是不靠谱啊.

为此, 据决定自己的搞个用起来简单, 又能良好支持反复跟踪而不用重启目标进程的工具.

AO

查看全文: http://www.udpwork.com/item/6604.html

这个贴用于记录自己碰到过的一些Java问题，会根据经验不断增加，以便总结，:)

case: 某应用在运行个一两天后就会把物理内存耗光

解决过程：

1、先按经验查了下有没有错误使用Inflater和Deflater，没有，于是继续；

2、继续上perftools，看看到底什么原因造成的，结果在6u21版本上看到的很诡异，是JVM_handle_linux_signal占了最多，觉得不靠谱，于是先升级成了6u26；

3、再分析，看到os::malloc占用了最多，但其他的就完全没头绪了；

4、在@JosephWang_CN的帮助下，图形分析下了perftools的stack trace，才发现还是unsafe_allocat

查看全文: http://www.udpwork.com/item/5624.html

前两天碰到一个很诡异的GC频繁的现象，走了不少弯路，N种方法查找后才终于查明原因了，在这篇blog中记录下，以便以后碰到这类问题时能更快的解决。

前两天一位同学找到我，说有个应用在启动后就一直Full GC，拿到GC log先看了下，确实是非常的诡异，截取的部分log如下：

2011-07-16T14:55:57.733+0800: 174042.063: [Full GC [PSYoungGen: 786432K->0K(917504K)] [ParOldGen: 728400K->728457K(1048576K)] 1514832K->728457K(1966080K) [PSPermGen: 84814K->84812K

查看全文: http://www.udpwork.com/item/5483.html

分享一下两个OOM Cases的查找过程，一个应用是Native OOM；另外一个应用其实没有OOM，只是每隔一段时间就会出现频繁FGC的现象，OOM的查找已经具备了不错的工具，但有些时候还是会出现很难查的现象，希望这两个排查过程的分享能给需要的同学带来一些帮助。

Native OOM的排查Case

之前的几个PPT里我都说到了，目前查找Native OOM最好的方法就是用google perftools了，于是挂上google perftools，等待应用再次native oom，很幸运，两天后，应用就再次native oom了，于是分析crash之前那段时间谁在不断的分配堆外的内存，pprof看到的结果主要是java.uti

查看全文: http://www.udpwork.com/item/4088.html

2010 年一整年基本都是做 DAL 的开发和维护，DAL 是用 Java 语言开发的，自然难免头疼的 GC 问题。

首先说明一点 DAL 是支持内置/外置两种方式的缓存，开始考虑到性能方面的问题，我们在部署 DAL 时候使用了内置缓存，这样缓存数据和 DAL 是处于同一个 JVM 实例的，每个 JVM 使用的内存都达到几个 G。有一段时间改过缓存策略后，DAL 的内存又增加了不少，GC 问题一度导致应用程序在几秒内失去响应。当时觉得这个问题是可以通过调整 JVM 参数来解决的，可是经过几个星期的调整还是没有收到显著的效果。接下来就把 DAL 的缓存外置，这样 DAL 的 JVM 和外置缓存服务（也是用 Java 开发的）的 JV

查看全文: http://www.udpwork.com/item/4078.html