aliveTime的专栏

<br /> <br /> <br />com.sun.btrace.BTraceUtils.sizeof(Object)方法返回的是对象的浅大小，也就是只是对象本身的大小，不包括对象依赖的传递闭包的对象大小

       普通情况下，Btrace脚本有诸多的限制：can not create new objects. can not create new arrays. can not throw exceptions. can not catch exceptions. can not make arbitrary instance or static method

       由于IDC的隔离性，在线上机部署YJP，JProfiler等GUI工具很是麻烦,尤其是排除线上故障的时候,一个简单实用的工或许能快速定位到问题,减少停机时间.       基于btrace写了一个最简单的profiler: 快速profile某个类的所有public方法的执行时间并输出.   安装:      首先安装btrace, 设置BTRACE_HOME环境变量

resin.conf 中有 设置，是resin内部有一个thread每隔10秒钟检查JVM剩余内存，如果free memory小于 2*min-free-memory，则执行Runtime.gc() 强制进行GC，如果使用-XX:+DisableExplicitGC 禁用显式调用GC，则该设置无效。对应的代码如下（com/caucho/server/resin/Resin.java）： long minFreeMemory = _server.getMinFreeMemory(); if (minFre

Java GC日志可以通过 +PrintGCDetails开启以ParallelGC为例YoungGC日志解释如下（图片源地址：这里） ：FullGC（图片源地址：这里）：一目了然，一图胜千言

curator简介Netflix curator 是Netflix公司开源的一个Zookeeper client library，用于简化zookeeper客户端编程，包含一下几个模块：curator-client - zookeeper client封装，用于取代原生的zookeeper客户端，提供一些非常有用的客户端特性curator-framework - zookeeper

如果java进程发生OOM, 代码是否可以catch住这个异常?答案是可以的. 测试代码如下:public class TestOOM{ public static void main(String[] args) throws Exception{ int ten_mb = 1024 * 1024 * 10; int count = 10; new Thread(){

众所周知，hadoop

一般在项目依赖比较复杂或者java运行的环境有问题时同一类型的jar包有不同版本存在，本质上说是JVM找不到某个类的特定方法，也就是说JVM加载了错误版本的类。出现该问题的情形一般有一下几种：   1、项目依赖复杂。不使用maven管理项目依赖时更容易出现该问题。              处理的方法是: 如果使用maven，执行maven dependency:tree 人工排除   2、运行环境问题。一般java web程序都运行在容器中，tomcat等。如果容器中已经存在了某个版本的jar包并已经加载

eclipse默认是无法调试JDK源代码的，即使添加了src.zip 作为source code也不能解析stack上的变量，只能看到类成员变量。原因很简单，JDK的源代码是使用 javac -g:none 参数进行编译的，所以代码里面没有任何的debug info。解决方式也同样简单：重新编译JDK的源代码。简单写了一个shell脚本，只要设置了 $JAVA_HOME 变量，就可以实现#!/bin/shif [ -z "$JAVA_HOME" ]then echo "Must set JAVA

Gson 对 Map 嵌套类型的序列化与反序列化样仅仅解决了gson对于嵌套的Map类型的序列化与反序列化，并且要求Map中的value为primative type orMap(代码42行，使用“{”作为判断是否为complex value type)

<br />      写一些Java框架的时候，经常需要通过反射get或者set某个bean的field，比较普通的做法是获取field后调用java.lang.reflect.Field.get(Object)，但每次都这样调用，能否有优化的空间呢？<br /> <br />答案是有。<br />第一种：<br />      由于每次都是重复的调用，所以想到了缓存每个bean的field，但这样做还是不够，所以想到了写一个code generator。通过生成代码的方式，get或者set每个bean的

simple profiler1、概述   做一个无侵入性的Java性能分析工具，使用的技术有：sun attach api, java instrument api, java bytecode, asm framework2、使用方式：   参数：   javapid                  - java 进程号   profile type            - profile  类型，参见profile类型介绍   class name            - 需要pro

      今天又有同事问起这个事情，所以写个blog记录一下。      在java 1.5的release notes里面可以看到这样一句话：     The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, th

        众所周知，btrace中可以使用 com.sun.btrace.BTraceUtils.sizeof(Object)来计算传入的对象的大小；jmap -histo中也可以显示heap中对象大小信息，到底这两个显示的object size是“浅大小” 还是 “深大小”？        简单测试一下：BTraceUtils.sizeof(Object)：        首先来看btrace，被测试代码如下：public class TestBtrace{ private sta

JVM 参数-XX:+PrintGCTimeStamps仅仅打印相对时间，其实还有一个flag可以让jvm像其他日志一样打印真实的时间

JVM的manageable参数可以通过jmx进行修改（参见这里）此处列出所有的JVM中manageable的参数列表（参见openjdk ./hotspot/src/share/vm/runtime/globals.hpp）

<br />链接地址：https://gist.github.com/925323<br /> <br />由于某些原因，我贴在这里，供自己参考。Correspondence between Sun/Oracle JDK, OpenJDK and HotSpot VM versionsbuild dateSun/Oracle JDK VersionOpenJDK VersionHotSpot VM Version2006-11-291.6.0-b1051.6.0-b1052007-03-141.6.0_01

最近hadoop系统在升级后发现一个诡异的问题: jps命令返回的都是process information unavailable, jstack, jmap等所有使用attach api的命令都有类似问题.以为是Jps有问题, 查看Jps源代码, 得知使用 jps -J-Djps.debug=true -J-Djps.printStackTrace=true 可以获得J