1.ART 深入浅出 - 为何 Thread.getStackTrace() 会崩溃？
2.老生常谈线程基础的源码几个问题
3.restTemplate设置单次访问超时时间
4.线程池中空闲的线程处于什么状态？
5.深入源码和内核，一篇文章彻底理解数据库的线程各种超时参数-事务超时/查询超时/连接超时/登录超时/套接字超时
6.Dubbo调用超时那些事儿

ART 深入浅出 - 为何 Thread.getStackTrace() 会崩溃？

       ART 深入浅出：Thread.getStackTrace() 崩溃原因剖析

       Thread.getStackTrace() 在卡顿检测中常被调用，但频繁调用可能导致崩溃，源码崩溃堆栈通常显示为：VMStack_getThreadStackTrace() -> ThreadList::SuspendThreadByPeer() 等。线程本文将逐步解析其崩溃机制。源码

       在 ART (Android Runtime) 的线程flash下雨代源码源码 Android 版本中，VMStack.cc 的源码 GetThreadStack 函数是关键，它涉及线程挂起和回调生成调用栈的线程过程。首先，源码通过 SuspendThreadByPeer() 函数挂起线程，线程然后回调生成调用栈，源码最后恢复线程。线程然而，源码这个过程可能因超时引发问题，线程例如当 SuspendThreadByPeer() 在线程状态检查中判断线程未挂起时，源码超时会触发 ThreadSuspendByPeerWarning()，严重时会导致 Runtime::Abort。

       通常，使用 ThreadList::SuspendThreadByThreadId() 函数可以避免这种 Crash，因为它在超时后只会产生警告，而不是终止。超时时间默认为 秒，如果线程长时间未能挂起，可能源于 ART 挂起线程的机制。在旧版 ART 中，挂起线程通过 ModifySuspendCount() 函数设置标志位，但在新版本中，这个逻辑已有所改变。

       深入探究，Java 的 Check Point 概念在其中起关键作用。解释执行的 switch/case 语句和机器码执行都有检查点，这些检查点会暂停线程执行，进行垃圾回收、调试等操作。当 Thread.getStackTrace() 触发挂起时，会进入 CheckSuspend() 函数，依据状态标志位决定挂起或执行检查点。真正的挂起操作会在析构函数中执行，通过 wait 函数挂起线程，直到其他线程执行到唤醒操作。

       总结来说，Thread.getStackTrace() 崩溃源于线程挂起操作与检查点执行的黑马趋向指标源码同步问题。当线程未能及时进入检查点，getStackTrace() 的等待时间过长，从而导致崩溃。理解了这个机制，就能避免此类问题的发生。

老生常谈线程基础的几个问题

       实现线程只有一种方式

       我们知道启动线程至少可以通过以下四种方式：

       实现Runnable接口

       继承Thread类

       线程池创建线程

       带返回值的Callable创建线程

       但是看它们的底层就一种方式，就是通过newThread()实现，其他的只不过在它的上面做了层封装。

       实现Runnable接口要比继承Thread类的更好：

       结构上分工更明确，线程本身属性和任务逻辑解耦。

       某些情况下性能更好，直接把任务交给线程池执行，无需再次newThread()。

       可拓展性更好：实现接口可以多个，而继承只能单继承。

       有的时候可能会问到启动线程为什么是start()方法，而不是run()方法，这个问题很简单，执行run()方法其实就是在执行一个类的普通方法，并没有启动一个线程，而start()方法点进去看是一个native方法。

       当我们在执行java中的start()方法的时候，它的底层会调JVM由c++编写的代码Thread::start，然后c++代码再调操作系统的create_thread创建线程，创建完线程以后并不会马上运行，要等待CPU的调度。CPU的调度算法有很多，比如先来先服务调度算法（FIFO），最短优先（就是对短作业的优先调度）、时间片轮转调度等。如下图所示：

线程的状态

       在Java中线程的生命周期中一共有6种状态。

       NEW：初始状态，线程被构建，但是还没有调用start方法

       RUNNABLE：运行状态，JAVA线程把操作系统中的就绪和运行两种状态统一称为运行中

       BLOCKED：阻塞状态，表示线程进入等待状态,也就是线程因为某种原因放弃了CPU使用权

       WAITING:等待状态

       TIMED_WAITING：超时等待状态，超时以后自动返回

       TERMINATED：终止状态，表示当前线程执行完毕

       当然这也不是我说的，源码中就是这么定义的：

publicenumState{ /***Threadstateforathreadwhichhasnotyetstarted.*/NEW,/***Threadstateforarunnablethread.Athreadintherunnable*stateisexecutingintheJavavirtualmachinebutitmay*bewaitingforotherresourcesfromtheoperatingsystem*suchasprocessor.*/RUNNABLE,/***Threadstateforathreadblockedwaitingforamonitorlock.*Athreadintheblockedstateiswaitingforamonitorlock*toenterasynchronizedblock/methodor*reenterasynchronizedblock/methodaftercalling*{ @linkObject#wait()Object.wait}.*/BLOCKED,/***Threadstateforawaitingthread.*Athreadisinthewaitingstateduetocallingoneofthe*followingmethods:*<ul>*<li>{ @linkObject#wait()Object.wait}withnotimeout</li>*<li>{ @link#join()Thread.join}withnotimeout</li>*<li>{ @linkLockSupport#park()LockSupport.park}</li>*</ul>**<p>Athreadinthewaitingstateiswaitingforanotherthreadto*performaparticularaction.**Forexample,athreadthathascalled<tt>Object.wait()</tt>*onanobjectiswaitingforanotherthreadtocall*<tt>Object.notify()</tt>or<tt>Object.notifyAll()</tt>on*thatobject.Athreadthathascalled<tt>Thread.join()</tt>*iswaitingforaspecifiedthreadtoterminate.*/WAITING,/***Threadstateforawaitingthreadwithaspecifiedwaitingtime.*Athreadisinthetimedwaitingstateduetocallingoneof*thefollowingmethodswithaspecifiedpositivewaitingtime:*<ul>*<li>{ @link#sleepThread.sleep}</li>*<li>{ @linkObject#wait(long)Object.wait}withtimeout</li>*<li>{ @link#join(long)Thread.join}withtimeout</li>*<li>{ @linkLockSupport#parkNanosLockSupport.parkNanos}</li>*<li>{ @linkLockSupport#parkUntilLockSupport.parkUntil}</li>*</ul>*/TIMED_WAITING,/***Threadstateforaterminatedthread.*Thethreadhascompletedexecution.*/TERMINATED;}

       下面是这六种状态的转换：

New新创建

       New表示线程被创建但尚未启动的状态：当我们用newThread()新建一个线程时，如果线程没有开始调用start()方法，那么此时它的火柴人flash源码状态就是New。而一旦线程调用了start()，它的状态就会从New变成Runnable。

Runnable运行状态

       Java中的Runable状态对应操作系统线程状态中的两种状态，分别是Running和Ready，也就是说，Java中处于Runnable状态的线程有可能正在执行，也有可能没有正在执行，正在等待被分配CPU资源。

       如果一个正在运行的线程是Runnable状态，当它运行到任务的一半时，执行该线程的CPU被调度去做其他事情，导致该线程暂时不运行，它的状态依然不变，还是Runnable，因为它有可能随时被调度回来继续执行任务。

       在Java中Blocked、Waiting、TimedWaiting，这三种状态统称为阻塞状态，下面分别来看下。

Blocked

       从上图可以看出，从Runnable状态进入Blocked状态只有一种可能，就是进入synchronized保护的代码时没有抢到monitor锁，jvm会把当前的线程放入到锁池中。当处于Blocked的线程抢到monitor锁，就会从Blocked状态回到Runnable状态。

Waiting状态

       我们看上图，线程进入Waiting状态有三种可能。

       没有设置Timeout参数的Object.wait()方法，jvm会把当前线程放入到等待队列。

       没有设置Timeout参数的Thread.join()方法。

       LockSupport.park()方法。

       Blocked与Waiting的区别是Blocked在等待其他线程释放monitor锁，而Waiting则是在等待某个条件，比如join的线程执行完毕，或者是notify()/notifyAll()。

       当执行了LockSupport.unpark()，或者join的线程运行结束，或者被中断时可以进入Runnable状态。当调用notify()或notifyAll()来唤醒它，它会直接进入Blocked状态，今日牛指标源码因为唤醒Waiting状态的线程能够调用notify()或notifyAll()，肯定是已经持有了monitor锁，这时候处于Waiting状态的线程没有拿到monitor锁，就会进入Blocked状态，直到执行了notify()/notifyAll()唤醒它的线程执行完毕并释放monitor锁，才可能轮到它去抢夺这把锁，如果它能抢到，就会从Blocked状态回到Runnable状态。

TimedWaiting状态

       在Waiting上面是TimedWaiting状态，这两个状态是非常相似的，区别仅在于有没有时间限制，TimedWaiting会等待超时，由系统自动唤醒，或者在超时前被唤醒信号唤醒。

       以下情况会让线程进入TimedWaiting状态。

       设置了时间参数的Thread.sleep(longmillis)方法。

       设置了时间参数的Object.wait(longtimeout)方法。

       设置了时间参数的Thread.join(longmillis)方法。

       设置了时间参数的LockSupport.parkNanos(longnanos)。

       LockSupport.parkUntil(longdeadline)方法。

       在TimedWaiting中执行notify()和notifyAll()也是一样的道理，它们会先进入Blocked状态，然后抢夺锁成功后，再回到Runnable状态。当然，如果它的超时时间到了且能直接获取到锁/join的线程运行结束/被中断/调用了LockSupport.unpark()，会直接恢复到Runnable状态，而无需经历Blocked状态。

Terminated终止

       Terminated终止状态，要想进入这个状态有两种可能。

       run()方法执行完毕，线程正常退出。

       出现一个没有捕获的异常，终止了run()方法，最终导致意外终止。

线程的停止interrupt

       我们知道Thread提供了线程的一些操作方法，比如stop()，suspend()和resume()，这些方法已经被Java直接标记为@Deprecated，这就说明这些方法是不建议大家使用的。

       因为stop()会直接把线程停止，期货sar指标源码这样就没有给线程足够的时间来处理想要在停止前保存数据的逻辑，任务戛然而止，会导致出现数据完整性等问题。这种行为类似于在linux系统中执行kill-9类似，它是一种不安全的操作。

       而对于suspend()和resume()而言，它们的问题在于如果线程调用suspend()，它并不会释放锁，就开始进入休眠，但此时有可能仍持有锁，这样就容易导致死锁问题，因为这把锁在线程被resume()之前，是不会被释放的。

interrupt

       最正确的停止线程的方式是使用interrupt，但interrupt仅仅起到通知被停止线程的作用。而对于被停止的线程而言，它拥有完全的自主权，它既可以选择立即停止，也可以选择一段时间后停止，也可以选择压根不停止。

       下面我们来看下例子：

publicclassInterruptExampleimplementsRunnable{ //interrupt相当于定义一个volatile的变量//volatilebooleanflag=false;publicstaticvoidmain(String[]args)throwsInterruptedException{ Threadt1=newThread(newInterruptExample());t1.start();Thread.sleep(5);//Main线程来决定t1线程的停止，发送一个中断信号,中断标记变为truet1.interrupt();}@Overridepublicvoidrun(){ while(!Thread.currentThread().isInterrupted()){ System.out.println(Thread.currentThread().getName()+"--");}}}

       执行一下，运行了一会就停止了

       主线程在调用t1的interrupt()之后，这个线程的中断标记位就会被设置成true。每个线程都有这样的标记位，当线程执行时，会定期检查这个标记位，如果标记位被设置成true，就说明有程序想终止该线程。在while循环体判断语句中，通过Thread.currentThread().isInterrupt()判断线程是否被中断，如果被置为true了，则跳出循环，线程就结束了，这个就是interrupt的简单用法。

阻塞状态下的线程中断

       下面来看第二个例子，在循环中加了Thread.sleep秒。

publicclassInterruptSleepExampleimplementsRunnable{ //interrupt相当于定义一个volatile的变量//volatilebooleanflag=false;publicstaticvoidmain(String[]args)throwsInterruptedException{ Threadt1=newThread(newInterruptSleepExample());t1.start();Thread.sleep(5);//Main线程来决定t1线程的停止，发送一个中断信号,中断标记变为truet1.interrupt();}@Overridepublicvoidrun(){ while(!Thread.currentThread().isInterrupted()){ try{ Thread.sleep();}catch(InterruptedExceptione){ //中断标记变为falsee.printStackTrace();}System.out.println(Thread.currentThread().getName()+"--");}}}

       再来看下运行结果，卡主了，并没有停止。这是因为main线程调用了t1.interrupt()，此时t1正在sleep中，这时候是接收不到中断信号的，要sleep结束以后才能收到。这样的中断太不及时了，我让你中断了，你缺还在傻傻的sleep中。

       Java开发的设计者已经考虑到了这一点，sleep、wait等方法可以让线程进入阻塞的方法使线程休眠了，而处于休眠中的线程被中断，那么线程是可以感受到中断信号的，并且会抛出一个InterruptedException异常，同时清除中断信号，将中断标记位设置成false。

       这时候有几种做法：

       直接捕获异常，不做处理，e.printStackTrace();打印下信息

       将异常往外抛出，即在方法上throwsInterruptedException

       再次中断，代码如下，加上Thread.currentThread().interrupt();

@Overridepublicvoidrun(){ while(!Thread.currentThread().isInterrupted()){ try{ Thread.sleep();}catch(InterruptedExceptione){ //中断标记变为falsee.printStackTrace();//把中断标记修改为trueThread.currentThread().interrupt();}System.out.println(Thread.currentThread().getName()+"--");}}

       这时候线程感受到了，我们人为的再把中断标记修改为true，线程就能停止了。一般情况下我们操作线程很少会用到interrupt，因为大多数情况下我们用的是线程池，线程池已经帮我封装好了，但是这方面的知识还是需要掌握的。感谢收看，多多点赞~

       作者：小杰博士

restTemplate设置单次访问超时时间

       在使用restTemplate时，理解其如何设置单次访问的超时时间至关重要。默认情况下，restTemplate通过SimpleClientHttpRequestFactory来实现，其底层逻辑基于socket连接。然而，可以替换默认实现，采用HttpComponentsClientHttpRequestFactory。

       ### 全局自定义超时时间

       要设定全局超时时间，可以通过Factory设置。具体操作时，需要替换默认实现为HttpComponentsClientHttpRequestFactory。接着，通过配置其内部的RequestConfig类来设定超时时间。RequestConfig包含socketTimeout（读取超时时间）和connectTimeout（连接超时时间）两个属性，明确这些设置后，便能控制请求超时。

       ### 单个请求超时时间设置

       了解了全局设置后，针对单个请求超时时间的设定显得更为直接。在HttpComponentsClientHttpRequestFactory的源码中，可以通过自定义`createRequest`方法来实现。通常，此方法返回的HttpContext默认为null，这意味着RequestConfig配置值为null。因此，需要自定义该方法以生成并设置所需的RequestConfig配置。

       为了适应不同线程环境，可以设计一个持有RequestConfig线程上下文对象的类，并将其实例化为线程私有变量。接着，创建一个继承自HttpComponentsClientHttpRequestFactory的子类，并重写`createHttpContext`方法，以应用自定义的RequestConfig。

       通过实例化CustomHttpRequestFactory类，可以灵活地在不同请求中应用自定义的超时设置。在实际应用中，这有助于避免因网络延迟或其他问题导致的超时错误。

       实践示例和详细代码可参考：blog.csdn.net/yaomingya...

线程池中空闲的线程处于什么状态？

       一:阻塞状态,线程并没有销毁,也没有得到CPU时间片执行;

       源码追踪:

       for (;;) {

       ...

        workQueue.take();

       ...

       }

       public E take()...{

       ...

       while (count.get() == 0) { / /这里就是任务队列中的消息数量

       notEmpty.await();

       }

       ...

       }

       public final void await()...{

       ...

       LockSupport.park(this);

       ...

       }

       继续往下:

       public static void park(Object blocker) {

       Thread t = Thread.currentThread();

       setBlocker(t, blocker);

       U.park(false, 0L);

       setBlocker(t, null);

       }

       private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();

       //线程调用该方法，线程将一直阻塞直到超时，或者是中断条件出现。

       public native void park(boolean isAbsolute, long time);

       上面就是java线程池中阻塞的源码追踪;

       二.对比object的wait()方法:

       @FastNative

       public final native void wait(long timeout, int nanos) throws InterruptedException;

       还有Thread的sleep() 方法:

       @FastNative

       private static native void sleep(Object lock, long millis, int nanos)throws...;

       可见,线程池中使用的阻塞方式并不是Object中的wait(),也不是Thread.sleep() ;

       这3个方法最终实现都是通过c&c++实现的native方法.

       三.在<<Java虚拟机(第二版)>>中,对线程状态有以下介绍:

       .4.3　状态转换

       Java语言定义了5种线程状态，在任意一个时间点，一个线程只能有且只有其中的一种

       状态，这5种状态分别如下。

       1)新建（New）：创建后尚未启动的线程处于这种状态。

       2)运行（Runable）：Runable包括了操作系统线程状态中的Running和Ready，也就是处于此

       状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间。

       3)无限期等待（Waiting）：处于这种状态的线程不会被分配CPU执行时间，它们要等待被

       其他线程显式地唤醒。以下方法会让线程陷入无限期的等待状态：

       ●没有设置Timeout参数的Object.wait（）方法。

       ●没有设置Timeout参数的Thread.join（）方法。

       ●LockSupport.park（）方法。

       4)限期等待（Timed Waiting）：处于这种状态的线程也不会被分配CPU执行时间，不过无

       须等待被其他线程显式地唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程

       进入限期等待状态：

       ●Thread.sleep（）方法。

       ●设置了Timeout参数的Object.wait（）方法。

       ●设置了Timeout参数的Thread.join（）方法。

       ●LockSupport.parkNanos（）方法。

       ●LockSupport.parkUntil（）方法。

       5)阻塞（Blocked）：线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等

       待着获取到一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状

       态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将

       进入这种状态。

       结束（Terminated）：已终止线程的线程状态，线程已经结束执行。

深入源码和内核，一篇文章彻底理解数据库的各种超时参数-事务超时/查询超时/连接超时/登录超时/套接字超时

       深入源码和内核，一篇文章彻底理解数据库的各种超时参数-事务超时/查询超时/连接超时/登录超时/套接字超时

       数据库在运行过程中，可能会遇到各种超时问题，尤其是在网络不稳定或业务高并发场景下。理解这些超时的原理、工作机制以及不同数据库中的超时参数设置，对于排查异常情况和优化应用性能至关重要。本文将带你深入了解数据库超时参数的细节。

       数据库的超时参数主要包括事务超时、查询超时、连接超时、登录超时和套接字超时。除了这些常见的超时参数，客户端的JDBC应用程序和服务端的数据库管理系统还可能在服务器上配置操作系统级别的基于TCP keep-alive的超时检测和保活机制，以及套接字级别的基于TCP keep-alive的超时检测和保活机制。

       事务超时，即transaction timeout，指限制事务中所有语句处理时间之和的最大值。事务超时通常在应用框架中进行配置，例如在Spring中使用注解@Transactional指定。

       查询超时，即query timeout，限制SQL语句的最大执行时间。当执行时间超过指定的超时时间，应用端的数据库驱动程序会抛出超时异常，并发送取消执行信号给数据库管理系统，由数据库管理系统取消执行。

       连接超时，即connectTimeout，驱动程序建立TCP连接的超时时间。

       登录超时，即loginTimeout，是数据库用户成功登录到数据库服务器的超时时间。考虑到登录过程中的TCP连接建立和认证，配置登录超时时通常需要大于连接超时。

       常规的套接字超时socket timeout同样适用于JDBC应用程序，用于检测和感知网络层面TCP连接异常，避免僵死连接造成的无限等待。

       登录超时、连接超时和套接字超时之间存在差异，但它们都与网络层面的通信和状态检查有关。在配置和理解这些超时参数时，需要区分它们的作用范围和相互关系。

       查询超时的工作机制在不同数据库管理系统和驱动下略有不同，但基本原理相似。通常通过独立线程跟踪语句执行时间，在超时后抛出错误，并通过底层连接发送取消执行信号给数据库管理系统。

       在配置常见数据库的套接字超时时，需要注意不同的数据库管理系统可能有不同的配置方式。了解和应用这些配置可以有效优化数据库性能和稳定性。

       客户端和服务器端通常都具备基于TCP keep-alive的超时检测和保活机制。在某些情况下，还可以配置套接字级别的基于TCP keep-alive的超时检测和保活机制，进一步提高网络通信的可靠性。

Dubbo调用超时那些事儿

       其实之前很早就看过Dubbo源码中关于超时这部分的处理逻辑，但是没有记录下来，最近在某脉上看到有人问了这个问题，想着再回顾一下。

开始

       从dubbo的请求开始，看看dubbo（2.6.6）在超时这块是怎么处理的：

com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeChannel#request(java.lang.Object, int)@Overridepublic ResponseFuture request(Object request, int timeout) throws RemotingException { if (closed) { throw new RemotingException(this.getLocalAddress(), null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");}// create request.Request req = new Request();req.setVersion(Version.getProtocolVersion());req.setTwoWay(true);req.setData(request);DefaultFuture future = new DefaultFuture(channel, req, timeout);try { channel.send(req);} catch (RemotingException e) { future.cancel();throw e;}return future;}DefaultFuture

       从返回值ResponseFuture类型可以看出，这是一个异步方法（不等同于Dubbo的异步调用）。那么调用超时的关键可以从ResponseFuture来看：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}

       可以看到这是一个接口，从request方法可以得知实现类是DefaultFuture，从构造函数入手：

public DefaultFuture(Channel channel, Request request, int timeout) { this.channel = channel;this.request = request;this.id = request.getId();this.timeout = timeout > 0 ? timeout : channel.getUrl().getPositiveParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);// put into waiting map.FUTURES.put(id, this);CHANNELS.put(id, channel);}

       可以得知每一个DefaultFuture都有一个id，并且等于requestId，timeout是从url中获取的配置，没有时默认ms。

       从代码的注释可以看到FUTURES这个map应该就是关键，是一个waiting map。

       DefaultFuture中还有一个方法：

public static void received(Channel channel, Response response) { try { DefaultFuture future = FUTURES.remove(response.getId());if (future != null) { future.doReceived(response);} else { logger.warn("The timeout response finally returned at "+ (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new Date()))+ ", response " + response+ (channel == null ? "" : ", channel: " + channel.getLocalAddress()+ " -> " + channel.getRemoteAddress()));}} finally { CHANNELS.remove(response.getId());}}

       可以看到调用的地方为：

       com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler#received

@Overridepublic void received(Channel channel, Object message) throws RemotingException { //省略一些代码} else if (message instanceof Response) { handleResponse(channel, (Response) message);//省略一些代码}}

       com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler#handleResponse

static void handleResponse(Channel channel, Response response) throws RemotingException { if (response != null && !response.isHeartbeat()) { DefaultFuture.received(channel, response);}}

       回到DefaultFuture.received，可以看到通过Response id从FUTURES中拿了一个DefaultFuture出来，然后调用了doReceived方法，也就是说Response id和Request id 相同。结下来看看doReceived做了什么：

private void doReceived(Response res) { lock.lock();try { response = res;if (done != null) { done.signal();}} finally { lock.unlock();}if (callback != null) { invokeCallback(callback);}}

       首先是加锁，然后通过唤醒了阻塞在Condition上的线程。看看什么地方会阻塞在done这个条件上：

@Overridepublic Object get(int timeout) throws RemotingException { if (timeout <= 0) { timeout = Constants.DEFAULT_TIMEOUT;}if (!isDone()) { long start = System.currentTimeMillis();lock.lock();try { while (!isDone()) { done.await(timeout, TimeUnit.MILLISECONDS);if (isDone() || System.currentTimeMillis() - start > timeout) { break;}}} catch (InterruptedException e) { throw new RuntimeException(e);} finally { lock.unlock();}if (!isDone()) { throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));}}return returnFromResponse();}

       是get方法，get方法确实在request请求后被调用：

(Result) currentClient.request(inv, timeout).get()

       可以看到get方法的大致逻辑为，先获取锁，然后循环判断isDone，并阻塞等到条件，当条件超时，如果任务完成，或者超过timeout结束循环，接着判断isDone，如果超时抛出TimeoutException。并且通过sent（request请求时间）是否>0（）来判断是clientSide还是serverSide超时。

       isDone逻辑如下：

@Overridepublic boolean isDone() { return response != null;}

       如果是正常Response，也有可能是超时的现象，可以看到get方法最后调用了一个函数：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}0TIMEOUT SIDE

       SERVER_TIMEOUT（服务端超时）： 这个就是正常的我们消费端请求一个RPC接口，服务端由于性能等一些原因处理时间超过了timeout配置时间。

       CLIENT_TIMEOUT：我们可以看到是通过sent(上面有说sent>0)这个来判断是否clientTimeout，那么这个sent什么时候改变呢？就在发送请求的地方：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}1

       也就是说handler.sent一旦调用成功返回，那么就不算clientSide Timeout了。那么CLIENT_TIMEOUT大概率就是由于client端网络，系统等原因超时。

原文：/post/