用 p6spy 来观察 Java 程序中执行的所有 SQL 语句(五. 结合 IronTrack SQL)

本想把 p6spy 结合 SQL Profiler 或 IronTrack SQL 的使用介绍掇凑于一块来写。简单点说,只是一贴上图样,篇幅便需拖拉难遂人愿,也好,索性把它们分成两个篇章。一来每篇主旨鲜明,二来五篇成一系列比起四更来的自然且吉利。

前面讲过 p6spy 本身就可利用 Log4j 的 SocketAppender 向远端发送日志,SQL Profiler 不过是在这个基础上作了进一步拓展。而接下来要说的 IronTrack SQL 就略有不同了,看它带的 p6spy.properties 文件,里面有 IronTrack SQL 给 p6spy 定制的一个模块:module.ibeam=com.irongrid.ibeam.server.IBeamFactory。它用到了 log4j-1.2.8.jar,不过还得研究下 Log4j 在其中所起的作来。现在就来介绍 p6spy 结合 IrconTrack SQL 的使用,最好是你知道如何单独使用 p6spy。压缩包里有文档:是 IronTrackSQL\docs\index.html。

p6spy + IronTrack SQL 观察 SQL 语句 阅读全文 >>

用 p6spy 来观察 Java 程序中执行的所有 SQL 语句(四. 结合 SQL Profiler)

p6spy 虽好,但把 SQL 语句输出到文件或是控制台中看起来有些吃力。若能图形界面展示出来便可一目了然,亲切许多。有种方法是配置 p6spy.properties 使用 Log4j 的 SocketAppender,然后启动 Log4j 的 org.apache.log4j.net.SocketServer 界面,或是在 Eclipse log4j plug-in 中也能观察所执行的 SQL 语句。

不过还有种更专业做法,本篇将介绍 p6spy 如何结合 Sql Profiler 或 IronTrack SQL 来使用,并附以贴图,来感受一下吧。也以此来完成关于 p6spy 的这个系列。其实你到后面也会发现,即便是用 Sql Pofier 的实现过程也是借助了 Log4j 的 SocketApender,你可以从它自己带的 p6spy.properties 文件中的配置看出来,即其中的 log4j.appender.SQLPROFILER_CLIENT=org.apache.log4j.net.SocketAppender 这么一个配置。 阅读全文 >>

用 p6spy 来观察 Java 程序中执行的所有 SQL 语句(二. Tomcat 下的配置)

在前篇 用 p6spy 来观察 Java 程序中执行的所有 SQL 语句(一. 引子) 大略介绍了 p6spy,并且在 http://www.p6spy.com/documentation/install.htm#install 也有 p6spy 在不同服务器下的安装方法。本文不打算依照官方的说明来做,我们让 Tomcat 的 Common 类加载器来加载 p6spy.jar 包,包含了 Tomcat 5/6 下的 p6spy 配置,数据库连接池实现用 C3P0,数据库为 Oracle,配置在一个与应用同名的单独的 xml 文件中,Tomcat 中是在应用的 META-INF/context.xml 文件中。步骤如下:

1. 软件准备

下载 Tomcat 5 或者 6 进行安装,不必多说。假设置 Tomcat 的目录为 $TOMCAT_HOME。
下载 p6spy-install.zip,解压缩 p6spy-install.zip,其中有 p6spy.jar 和 spy.properties
准备好数据库的驱动包,比如 Oracle 的 classes12.jar,和 C3P0 实现包,如 c3p0-0.9.0.2.jar。 阅读全文 >>

用 p6spy 来观察 Java 程序中执行的所有 SQL 语句(一. 引子)

一个企业应用程序的性能瓶颈可能会在硬件配置、网络方面、程序代码、应用服务器配置、数据库配置、SQL 语句。这里我把本文的关注点 SQL 无意间放在了最后,其实它不并不意味着最后考虑的,而是过程中就要时刻留意的。

SQL 语句的优化总得把所执行语句抓出来瞧瞧,分析分析。如果直接用 JDBC 或者是类 iBatis 的东西来访问数据库,那所执行的 SQL 语句是明确的,而现在的项目大多会用 ORM 组件,例如 Hibernate、JPA、CMP、TopLink 都有自己特定的查询语法,最终当然要转换成 SQL 语句的,所以会生成什么样的 SQL 语句就不甚明了,若人为的看着专有查询语句来相象出 SQL 语句并非易事。虽然 Hibernate 设置 show_sql=true 时也能打印出生成的 SQL(带?号参数),配合详细的日志参数值也可以对上,不过挺麻烦的。 阅读全文 >>

有关于 JVM 的垃圾收集(二)

自适应收集器

在第一篇:有关于 JVM 的垃圾收集(一)  中谈到过几种垃圾收集的算法,然而我们的 JVM 启动之后并不要求彻头彻尾的死板的使用一种垃圾收集算法,固定的算法参数。因为某种情况下某些垃圾收集算法工作得更好,而别外一些收集算法在另外的情况下工作得更好,所以自适应的垃圾收集技术应运而生。自适应算法监视堆中的情形,并且对应的调整为合适的垃圾收集技术。或能是换一种垃圾收集算法,或者是调整当前算法参数,或者把堆划分为子堆,同时在不同的子堆中使用不同的算法。

简述火车算法

垃圾收集一般都会停止整个程序的运行来查找和收集垃圾对象,它们可能在程序执行的任意时刻暂停,并且暂停的时间也无法确定。垃圾收集也可能使得程序对事件响应迟钝,无法满足实时系统的要求。如果一种垃圾收集算法可能导致用户可察觉的到的停顿或者使得程序无法适合实时系统的要求,这种算法被称作破坏性。垃圾收集算法的还有一个基本目标是使本质上的破坏性尽可能少,如果可能的话,尽可能消除这种破坏性。 阅读全文 >>

简单例子演示如何进行类的热加载(Hot Deployment)

应用服务器一般都支持热部署(Hot Deployment),更新代码时把新编译的确类替换旧的就行,后面的程序就执行新类中的代码。这也是由各种应用服务器的独有的类加载器层次实现的。那如何在我们的程序中也实现这种热加载功能呢?即要在虚拟机不关闭的情况下(比如一个),换个类,JVM 就知道加载这个新类,执行新类中的逻辑呢?下面就简单演示这样一个热加载的例子,首先大致了解一下类加载器。

标准 Java 启动器的类加载器层次

1. 引导类加载器(bootstrap):   加载内核 API,如 rt.jar(java.lang、java.io 等)
2. 扩展类加载器(extension):   加载的默认扩展来自于 jre/lib/ext
3. 系统类加载器(system):       类路径上的类,如 com.unmi.*

说明:这只是标准 Java 启动器运行程序时的类加载器层次,像应用服务器中的类加载器通常会多一两层,也是在这个基础上的延伸。上面的类加载层次存在自上而下的委托关系,委托加载不在这里细讲。 阅读全文 >>

有关于 JVM 的垃圾收集(一)

Java 中使用 new、newarray、anewarray 和 multianewarray 指令来创建的对象,当这些对象不再使用时由垃圾收集来释放。那么 反序列化等都是间接使用了前面的某个指令, clone()  是个本地方法?

JVM 规范不需要任何特定的垃圾收集技术,甚至也没要求有垃圾收集机制。大概只是说不需要手工释放内存,具体怎么实现各 JVM 自行决定。

GC 除了释放不再被引用的对象,还要处理堆碎片,整理出连续的空闲空间才能放得下新的对象。不至于出现总的空闲空间足够,但碎片太多而报出 "Out of Memory" 的异常。

GC 有两个好处:一个是提高了生产率,不用埋头于 Memory Link 的有时甚至是逐行的检查;二,GC 也是 Java 安全策略的一部分,有了它不至于因错误的释放内存而导至 JVM 崩溃。但是 GC 的一个潜在缺陷影响了程序的性能,它需要一直在后台不时的做些事情,而且实时性也有所欠缺。 阅读全文 >>

让 Java 轻松乐动起来,使用 JFugue 制作自己的音乐

学过或用过 Basic 的朋友大约还会记得,在 Basic 里要演奏(当时还是从 PC 喇叭里发出的,现在也能走声卡了)一段 哆来咪发唆拉西哆 可以写成:

直接用 JDK 可没有这么简单,虽然 JDK 1.3 开始就引入了 Java Sound API 处理 MIDI(Musical Instrument Digital Interface),可是它的接口很难使用,另外,Sun 也专为视、音频的捕获、回放、格式转换提供了 Java Media Framework API (JMF),但不能用来创作。有一个开源的组件 JFugue(http://www.jfugue.org/),它能让你尽显音乐方面的天赋,给你一个高级易用的接口来操作 Java Sound,制作自己的 MIDI 音乐。 阅读全文 >>

碰到一个不知如何解释的 Java 控制台程序的内存问题

有一 Java 控制台程序,启动经过一段时间之后从 Windows 任务管理器里看它所占用的内存稳定在 540M 左右。

启动参数是:-Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128

但只要你把那个控制台窗口最小化后,观察到的内存用瞬间下降到 100 多M,有时候甚至是几十M。然后不管是窗口保持最小化还是恢复了,它所占用的内存又以几十M几十M的上扬,直至先前的 540 M 左右。每次最小化窗口都可以观察到这种现象。

控制台窗口的参数:屏幕缓冲区大小:宽 120;高 300。窗口大小:宽 120;高 40。

不知道在控制台窗口最小化那时,JVM 做了些什么事情能让内存骤降下来,而复又升回去。

利用 Ant 的 SQL Task 来实现自己的 Java 执行 SQL 脚本文件的功能

前面记载过一篇 Java 执行 SQL 脚本文件,这里边完全是由自己写代码来分离出脚本中的每一个 SQL 语句的,有不少缺陷。当时还不太清楚 ANT 本身提供了功能很强的执行 SQL 语句和脚本的 SQL Task 可用。以下依次简单介绍如何在 build.xml 中执行 SQL 语句或脚本;Java 代码中如何调用 ant 的 SQLExec 类执行 SQL 脚本,最后考虑  ant.jar 的个头说大也不小,1M 多,如果只用于执行 SQL 脚本,则绝大部分代码就是垃圾,所以从同抽离出需要的两个类 JDBCTask 和 SQLExec,完全去除了对 ant.jar 包的依赖。

有关 ant 的更详细的记录请参见,http://ant.apache.org/manual/CoreTasks/sql.html阅读全文 >>