问题表象 |
问题描述
1.最近有项目组的童鞋反馈,web页面频繁出现假死的状态。
2.web页面的假死出现是概率事件,且无法确定假死的引发原因。
3.是在一定的操作之后出现的,但是无法确定究竟是哪些操作引发这些操作。
问题分析 |
初步分析
我们都知道web容器一般都是单实例多线程的方式工作的,当页面发起请求后,tomcat发分配一个线程进行当前请求的处理,当出现页面假死,说明是由于某种原因导致了线程在等待某种资源,可以是IO、网络响应、数据库连接、等待锁等等,所以需要首先确定该线程是在等待什么资源。
经过初步分析,可以知道是线程阻塞导致web不能够及时返回给页面响应,导致页面出现假死的情况。所以首先确定导致线程阻塞的原因。
确定线程是由于什么原因导致的阻塞其实也是比较简单的,可以使用jstack工具,到出现阻塞现象后,使用jstack工具查看器堆栈,看下是等待什么。也可以使用Eclipse的debug功能,将当前线程suspend。在这里我采用第二种方式。
操作步骤
在本地以Debug方式启动Tomcat应用,模拟一些操作,尽量将假死项目重现,开发人员根据以往的映像去操作一些功能,过了若干时间后,果然出现了假死现象。由于是debug方式启动所以查看其debug视图,发现启动了3个http线程,下图中红色部分标示的位置。
通过右击suspend挂起线程,发现有一个线程确实被阻塞掉了
观察堆栈可以确定是到连接池中去获取连接,但是当前连接池中无可用的连接,导致线程阻塞出现页面假死现象。
进一步分析
很明显这个是由于连接泄露导致无可用连接,所引起的线程阻塞,页面假死。查看连接池配置:
driver=oracle.jdbc.driver.OracleDriver
url=jdbc:oracle:thin:@127.0.0.1:1521:orcl
username=****
password=****
active=20
minidle=20
maxidle=20
maxwait=-1
出现连接泄露问题是较为难定位的问题,因为问题的表象离问题的根源较远,并没有直接的联系,所以只能凭经验和感觉去分析,另外出现该情况应当尽量将连接池连接个数配置改小,这样可以有效的拉近问题表象和问题根源之间的距离,减小问题重现的成本和最大化问题重现的概率。然后根据BTrace来进行分析。但是我们这里有BTrace这个利器来进行动态诊断。
诊断思路
只要跟踪所有的调用过BasicDataSource.getConnection这个方法的地方,然后在看看那些方法调用以后没有关系连接,而关闭连接的地方并非是Connection的close方法,需要对连接池的工作原理有一定的了解。
如上图,连接池持有Connection代理的引用,用来维护Connection,而Connection代理实现了JDBC,通过Connection代理来操作驱动程序,在oracle中是oracle.jdbc.driver.T4CConnection。
实际上连接池主要是通过PoolableConnection作为代理类,持有T4CConnection的引用,完成对数据的操作,并且自己实现了java.sql.Connection接口,我们看下close方法的具体实现。
- /**
- * Returns me to my pool.
- */
- public synchronized void close() throws SQLException {
- if (_closed) {
- // already closed
- return;
- }
- boolean isUnderlyingConectionClosed;
- try {
- isUnderlyingConectionClosed = _conn.isClosed();
- } catch (SQLException e) {
- try {
- _pool.invalidateObject(this); // XXX should be guarded to happen at most once
- } catch(IllegalStateException ise) {
- // pool is closed, so close the connection
- passivate();
- getInnermostDelegate().close();
- } catch (Exception ie) {
- // DO NOTHING the original exception will be rethrown
- }
- throw (SQLException) new SQLException("Cannot close connection (isClosed check failed)").initCause(e);
- }
- if (!isUnderlyingConectionClosed) {
- // Normal close: underlying connection is still open, so we
- // simply need to return this proxy to the pool
- try {
- _pool.returnObject(this); // XXX should be guarded to happen at most once
- } catch(IllegalStateException e) {
- // pool is closed, so close the connection
- passivate();
- getInnermostDelegate().close();
- } catch(SQLException e) {
- throw e;
- } catch(RuntimeException e) {
- throw e;
- } catch(Exception e) {
- throw (SQLException) new SQLException("Cannot close connection (return to pool failed)").initCause(e);
- }
- } else {
- // Abnormal close: underlying connection closed unexpectedly, so we
- // must destroy this proxy
- try {
- _pool.invalidateObject(this); // XXX should be guarded to happen at most once
- } catch(IllegalStateException e) {
- // pool is closed, so close the connection
- passivate();
- getInnermostDelegate().close();
- } catch (Exception ie) {
- // DO NOTHING, "Already closed" exception thrown below
- }
- throw new SQLException("Already closed.");
- }
- }
而获取连接的代码是通过PoolingDataSource的getConnection进行获取的代码如下:
- /**
- * Return a {@link java.sql.Connection} from my pool,
- * according to the contract specified by {@link ObjectPool#borrowObject}.
- */
- public Connection getConnection() throws SQLException {
- try {
- Connection conn = (Connection)(_pool.borrowObject());
- if (conn != null) {
- conn = new PoolGuardConnectionWrapper(conn);
- }
- return conn;
- } catch(SQLException e) {
- throw e;
- } catch(NoSuchElementException e) {
- throw new SQLNestedException("Cannot get a connection, pool error " + e.getMessage(), e);
- } catch(RuntimeException e) {
- throw e;
- } catch(Exception e) {
- throw new SQLNestedException("Cannot get a connection, general error", e);
- }
- }
可以非常清楚的看到,就是通过该方法释放连接到连接池中,供后续的业务代码进行调用。
到这里基本的思路已经出来了,只要跟踪PoolingDataSource的getConnection方法和PoolableConnection的close方法就可以知道究竟哪些业务代码只调用了获取连接而没有调用close方法进行释放连接,导致连接泄露。
BTrace利器 |
通过编写BTrace脚本进行分析跟踪,只要业务代码在调用完getConnection方法后调用了close就说明没有问题,也就是getConnection方法和close方法成对出现,如果只调用了getConnection方法而没有调用close方法那就说明该业务代码有连接泄露。
- import com.sun.btrace.annotations.*;
- import static com.sun.btrace.BTraceUtils.*;
- @BTrace public class BTraceConnection {
- @Export private static long openedCount;
- @Export private static long closedCount;
- @OnMethod(clazz="/.*PoolingDataSource/", method="getConnection", location=@Location(kind.RETURN))
- public static void m(@return Object obj) {
- openedCount++;
- println("One connection is opened!");
- println(obj);
- Threads.jstack();
- }
- @OnMethod(clazz="/.*PoolableConnection/", method="close")
- public static void d(@Self Object obj) {
- closedCount++;
- println("One connection is closed!");
- println(obj);
- Threads.jstack();
- }
- @OnExit
- public static void f(){
- print("Total opened connection:");
- println(openedCount);
- print("Total closed connection:");
- println(closedCount);
- }
- }
将连接池个数修改为3,启动应用,使用jps输出应用pid,
运行命令btrace <pid> BTraceConnection.java > trace.log
日志分析 |
输出结果
- One connection is opened!
- org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper@1d6fc56
- org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
- ..................
- com.***************************.dao.UserDAO.checkUserState(UserDAO.java:142)
- ..................
- java.lang.Thread.run(Thread.java:619)
- One connection is opened!
- ..................
- Total opened connection:61
- Total closed connection:57
部分无用内容有删减,发现总共获取了61次connection,释放了57次connection,com.***************************.dao.UserDAO.checkUserState(UserDAO.java:142)该方法没有释放连接,最终定位出了有问题的方法。
相关推荐
在实际使用BTrace时,开发者需要注意以下几点: - BTrace脚本必须遵循安全模式,避免修改程序执行流程,以防止对应用程序造成不良影响。 - 编写BTrace脚本需要熟悉Java语法和BTrace API,如`@OnMethod`注解用于指定...
在实际应用中,Btrace提供了丰富的API,允许开发者编写自定义的脚本来监控特定的代码段。这些脚本使用Groovy语言编写,易于理解和调试。同时,Btrace还支持可视化界面,便于查看和分析收集到的数据。此外,Btrace还...
BTrace是一款强大的Java应用动态追踪工具,它允许开发者在运行时对Java应用程序进行性能分析和诊断,而无需修改源代码或重新部署应用。这个版本可能是对早期版本的改进,包含了修复的bug、新的功能或性能优化。 ...
BTrace,全称为“Bytecode Tracing”,是一款强大的动态代码插桩工具,它允许开发者在运行时对Java应用程序进行性能分析和诊断。BTrace 1.3.9是其一个重要版本,特别针对JDK 1.8进行了优化,同时支持Maven编译构建,...
Btrace通过分析和修改类文件,实现在运行时动态插入监控代码,而无需重新编译或重启应用。 **使用场景** Btrace 可用于多种场景,包括但不限于: 1. 性能瓶颈分析:实时追踪方法调用,找出耗时较长的操作。 2. 错误...
BTrace的动态跟踪特性使得开发者可以在实际运行环境中捕获到性能问题,这比通过模拟或预测来分析性能要准确得多。 在压缩包文件"btraceio-btrace-9933f19"中,我们可以推测这是BTrace的一个版本或者构建,其中可能...
Btrace 是一款强大的Java应用程序诊断工具,它允许开发者在不修改或重启应用的情况下,实时监控和分析运行中的Java程序。这款工具的核心特性在于其无侵入性,对于繁忙的生产环境而言,这意味着可以在不影响系统正常...
**BTrace 自我总结测试代码** BTrace 是一个强大的、安全的、动态的Java应用程序诊断工具,由Sun Microsystems(现已被Oracle...这个自我学习测试代码集是一个很好的起点,可以帮助你掌握BTrace的基本用法和实际应用。
BTrace是一款强大的Java诊断工具,专用于实时、安全地进行生产环境中的应用程序性能监控和故障排查。它的核心特性在于能够在不中断程序运行的情况下,动态插入代码进行跟踪和分析,这对于理解复杂的系统行为和定位...
5. **应用实例**:BTrace常用于诊断性能瓶颈、检测线程死锁、监控内存使用、分析SQL查询等。例如,可以创建一个脚本来记录所有数据库访问,以找出慢查询。 6. **与其他工具集成**:BTrace也可以与持续集成系统、...
Btrace 在实际项目中有着广泛的应用,例如,它可以用来跟踪 SQL 查询时间、检测线程阻塞、监控内存泄漏,甚至检测并发问题。熟练掌握 Btrace,能够帮助开发者更好地理解和优化 Java 应用的性能,从而提升整体系统...
标题 "bTrace跟踪线程堆栈" 涉及到的是在Java开发中对线程堆栈进行监控和分析的技术,主要使用了开源工具bTrace。bTrace是一款强大的、无侵入式的Java运行时代码注入工具,允许开发者在运行中的Java应用上动态添加...
BTrace 是一个强大的、安全的、动态的Java应用程序诊断工具,它允许开发者在运行时对Java应用进行细粒度的监控和性能分析。BTrace利用了Java的动态代理机制(Java Agent)和ASM字节码库,能够在不中断程序运行的情况...
【标题】"btrace workbench" 是一个专为Java开发者设计的强大工具,它与jvisualvm结合使用,提供了深入的应用程序性能分析能力。BTrace(Business Trace)是一种动态跟踪工具,允许开发者在运行时对Java应用程序进行...
【btrace.jar】是一款强大的Java在线诊断工具,它允许开发者在不重启应用程序的情况下,实时地对Java程序进行动态追踪和分析。这个工具的核心价值在于它能够帮助我们在生产环境中无侵入地解决性能问题或者追踪特定的...
1.btrace扩展是在btrace已由功能上进行的扩展,原有功能和使用方式依然没变。目前版本扩展了两个功能:接口时间监控和接口时间调用树监控。扩展之后的btrace功能使用时都不需要写btrace脚本。 2.使用接口时间监控...
在实际应用中,BTrace测试可以用于各种场景,例如: 1. **性能瓶颈查找**:通过监控关键方法的执行时间和调用频率,找出系统中的性能瓶颈。 2. **内存泄漏检测**:监控对象的创建和销毁,辅助排查内存泄漏问题。 3....
BTrace是一款强大的Java应用程序动态跟踪工具,它允许开发者在不修改源代码或重新启动应用的情况下,对正在运行的Java应用程序进行实时的性能分析和诊断。这款工具的核心在于其字节码注入技术,它能够动态地在类的...
Btrace:java性能调优及问题追踪工具 Btrace:java性能调优及问题追踪工具
Btrace的VisualVM插件使我们能够在VisualVM界面直接管理和执行Btrace脚本,更加直观地查看和分析应用程序的运行状态。 1. **安装VisualVM插件**:打开VisualVM,选择“Tools” -> “Plugins”,在插件市场中搜索并...