精华内容
下载资源
问答
  • 服务器开发之大量time_wait 和 close_wait现象(该文的直接有代码) https://blog.csdn.net/haolipengzhanshen/article/details/80808435 状态变化的解释过程: 从客户端来看: 1.客户端主动断开连接时,会先发送FIN包...

    服务器开发之大量time_wait 和 close_wait现象(该文的直接有代码)

    https://blog.csdn.net/haolipengzhanshen/article/details/80808435

    在这里插入图片描述

    关闭TCP时,状态变化的解释过程:

    从客户端来看:

    1.客户端主动断开连接时,会先发送FIN包,客户端此时进入FIN_WAIT_1状态;

    2.客户端收到服务器的ACK包(对步骤1中FIN包的应答)后,客户端进入FIN_WAIT_2状态;

    3.客户端接收到服务器的FIN包并回复ACK包给服务端,然后客户端进入TIME_WAIT状态,此时会等待2个MSL的时间,

    确保发送的ACK包是否达到了对端。

    4.客户端在等待了2个MSL的时间没有收到服务器重传的FIN包,就默认ACK数据包已经抵达了对端。

    从服务端来看:

    1.服务器收到客户端发送的FIN数据包后,回复ACK包给客户端,此时服务器进入CLOSE_WAIT状态

    2.等待服务器将剩余的数据全部发送给客户端时,然后执行断开操作,(老夫把该做的事都做了,然后再给这小子发送FIN包来结束,哈哈,姜还是老的辣!)

    服务器向客户端发送出FIN包后,服务器端进入LAST_ACK状态,等待最后一个ACK确认包。

    3.服务端收到客户端发送的ACK包后,从LAST_ACK状态转为CLOSED状态,服务器正式关闭了

    示例:
    用实例来说明如何正确关闭TCP连接

    client.c

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <unistd.h>
    #include <sys/socket.h>
    #include <netinet/in.h>
    #include <arpa/inet.h>
     
     
    #define MAXLINE 80
    #define SERV_PORT 8000
     
     
    int main(int argc, char *argv[])
    {
        struct sockaddr_in servaddr;
        char str[MAXLINE] = "test ";
        int sockfd, n;
     
     
    	while(1)
    	{
    		sockfd = socket(AF_INET, SOCK_STREAM, 0);
     
     
    	    bzero(&servaddr, sizeof(servaddr));
    	    servaddr.sin_family = AF_INET;
    	    inet_pton(AF_INET, "192.168.254.26", &servaddr.sin_addr);
    	    servaddr.sin_port = htons(SERV_PORT);
     
     
    		connect(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr));
    		write(sockfd, str, strlen(str));
     
     
    		close(sockfd);
    		sleep(2);
    	}
     
     
        return 0;
    }
    

    server端代码

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <iostream>
     
     
    #include <sys/mman.h>
    #include <sys/stat.h>        /* For mode constants */
    #include <fcntl.h>           /* For O_* constants */
     
     
    #include <unistd.h>
    #include <arpa/inet.h>
     
     
    using namespace std;
     
     
    #define LENGTH 128
    #include "netinet/in.h"
    #define MAXLINE 80
    #define SERV_PORT 8000
     
     
    int main(int argc,char** argv)
    {
    	struct sockaddr_in servaddr, cliaddr;
        socklen_t cliaddr_len;
        int listenfd;
        char buf[MAXLINE];
        char str[INET_ADDRSTRLEN];
        //int i, n;
        int  n;
    	//创建socket
        listenfd = socket(AF_INET, SOCK_STREAM, 0); 
    	//设置端口重用
        int opt = 1;
        setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); 
        //fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFL, 0) | O_NONBLOCK);
    
    
     bzero(&servaddr, sizeof(servaddr));
    servaddr.sin_family = AF_INET;
    
    
    inet_pton(AF_INET,"192.168.254.26",&(servaddr.sin_addr.s_addr));
    //servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
    servaddr.sin_port = htons(SERV_PORT);
    
    bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr));
    
    
    listen(listenfd, 20);
    
    
    printf("Accepting connections ...\n");
    while (1)
    {
        cliaddr_len = sizeof(cliaddr);
        int connfd = accept(listenfd,
                (struct sockaddr *)&cliaddr, &cliaddr_len);
    
    	//while(1)
    	{
            n = recv(connfd, buf, MAXLINE,0);
            if (n == 0)
    		{
    			//对端主动关闭
                printf("the other side has been closed.\n");
                //break;
            }
            printf("received from %s at PORT %d len = %d\n",
                   inet_ntop(AF_INET, &cliaddr.sin_addr, str, sizeof(str)),
                   ntohs(cliaddr.sin_port),n);
    	}
        //测试:模拟CLOSE_WAIT状态时,将close(connfd);这句代码注释
    
        close(connfd);
    }
    
    return 0;
    

    }

    其中特别重要的部分如下图所示:
    在这里插入图片描述
    测试代码中,当recv的返回值为0时(对端主动关闭连接),会跳出while(1)循环,此时正确做法是调用close关闭tcp连接。

    此处我们为了测试,故意将close(connfd)这句代码注释掉,注释后服务器对于客户端发送的FIN包不会做回应,一直保持close_wait状态。


    我们来分析,什么情况下,连接处于CLOSE_WAIT状态呢?
    在被动关闭连接情况下,在已经接收到FIN,但是还没有发送自己的FIN的时刻,连接处于CLOSE_WAIT状态。
    通常来讲,CLOSE_WAIT状态的持续时间应该很短,正如SYN_RCVD状态。但是在一些特殊情况下,就会出现连接长时间处于CLOSE_WAIT状态的情况。

    出现大量close_wait的现象,主要原因是某种情况下对方关闭了socket链接,但是我方忙与读或者写,没有关闭连接。
    在被动关闭方,代码需要判断socket,一旦读到0(用read()或者recv()之类的函数),断开连接,read返回负,检查一下errno,如果不是AGAIN,就断开连接。

    ----------------------------华丽的分割-------------------------------------------------------------------

    服务器中判断客户端socket断开连接的方法、服务器正确关闭socket的方法

    https://www.cnblogs.com/jacklikedogs/p/3976208.html
    如果服务端的Socket比客户端的Socket先关闭,会导致客户端出现TIME_WAIT状态,占用系统资源。
    所以,必须等客户端先关闭Socket后,服务器端再关闭Socket才能避免TIME_WAIT状态的出现。

    1, 如果服务端的Socket比客户端的Socket先关闭,会导致客户端出现TIME_WAIT状态,占用系统资源。

    所以,必须等客户端先关闭Socket后,服务器端再关闭Socket才能避免TIME_WAIT状态的出现。

    2, 在linux下写socket的程序的时候,如果尝试send到一个disconnected socket上,就会让底层抛出一个SIGPIPE信号。

    client端通过 pipe 发送信息到server端后,就关闭client端, 这时server端,返回信息给 client 端时就产生Broken pipe 信号了。

    当服务器close一个连接时,若client端接着发数据。根据TCP协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了。
    根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止、退出),所以client会退出。若不想客户端退出可以把SIGPIPE设为SIG_IGN 如: signal(SIGPIPE,SIG_IGN);
    这时SIGPIPE交给了系统处理。

    这个信号的缺省处理方法是退出进程,大多数时候这都不是我们期望的。因此我们需要重载这个信号的处理方法。调用以 下代码,即可安全的屏蔽SIGPIPE:
    struct sigaction sa;
    sa.sa_handler = SIG_IGN;
    sigaction( SIGPIPE, &sa, 0 );
    服务器采用了fork的话,要收集垃圾进程,防止僵尸进程的产生,可以这样处理:
    signal(SIGCHLD,SIG_IGN); 交给系统init去回收。
    这里子进程就不会产生僵尸进程了。

    判断连接断开的方法

    法一:

    当recv()返回值小于等于0时,socket连接断开。但是还需要判断 errno是否等于 EINTR,如果errno == EINTR 则说明recv函数是由于程序接收到信号后返回的,socket连接还是正常的,不应close掉socket连接。

    法二:

    struct tcp_info info;
    int len=sizeof(info);
    getsockopt(sock, IPPROTO_TCP, TCP_INFO, &info, (socklen_t *)&len);
    if((info.tcpi_state==TCP_ESTABLISHED)) 则说明未断开 else 断开

    法三:

    若使用了select等系统函数,若远端断开,则select返回1,recv返回0则断开。其他注意事项同法一。

    法四:

    int keepAlive = 1; // 开启keepalive属性
    int keepIdle = 60; // 如该连接在60秒内没有任何数据往来,则进行探测
    int keepInterval = 5; // 探测时发包的时间间隔为5 秒
    int keepCount = 3; // 探测尝试的次数.如果第1次探测包就收到响应了,则后2次的不再发.

    setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void )&keepAlive, sizeof(keepAlive));
    setsockopt(rs, SOL_TCP, TCP_KEEPIDLE, (void
    )&keepIdle, sizeof(keepIdle));
    setsockopt(rs, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));
    setsockopt(rs, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));

    设置后,若断开,则在使用该socket读写时立即失败,并返回ETIMEDOUT错误

    法五:

    自己实现一个心跳检测,一定时间内未收到自定义的心跳包则标记为已断开。

    法六:一种完善但复杂的方案:

    (1)定义receive函数

    最近试验发现,当客户端Socket关闭时,服务端的Socket会接收到0字节的通知。

    private int Receive(StringBuilder sb)
    
    {
    int read = 0, total = 0;
    
    if (_Client != null)
    
    {
    
        try
    
        {
    
            byte[] bytes = new byte[SIZE];
    
            int available = _Client.Available;
    
            do
    
            {
    
                read = _Client.Receive(bytes);//如果客户端Socket关闭,_Client会接受到read=0
    
                total += read;
    
                if (read > 0)
    
                    sb.Append(_Server.DefaultEncoding.GetString(bytes, 0, read));
    
    
    
            } while (read > 0 && total < available);
    
        }
    
        catch (SocketException)
    
        {
    
            CloseSocket();
    
        }
    
    }
    
    if (_Server.TraceInConsole && total > 0)
    
    {
    
        Console.WriteLine("Receive:" + total + "======================================");
    
        Console.WriteLine(sb.ToString());
    
    }
    
    return total;
    

    }

    (2)利用0字节接收条件判断客户端Socket的关闭,调用TryCloseSocket()函数。

    private void ThreadHandler()
    
    {
    
       if (_Server.TraceInConsole)
        Console.WriteLine("Begin HttpRequest...");
    
    try
    
    {
    
        while (true)
    
        {
    
            StringBuilder sb = new StringBuilder();
    
            int receive = Receive(sb);
    
            if (receive > 0)
    
            {
    
                _Server.ReadRequest(this, sb.ToString());
    
                _Server.Response(this);
    
                _Server.ResponseFinished(this);
    
            }
    
            else
    
            {
    
                TryCloseSocket();
    
            }
    
            if (_Client == null)
    
                break;
    
        }
    
    }
    
    catch (Exception ex)
    
    {
    
        if (_Server.TraceInConsole)
    
            Console.WriteLine(ex.Message);
    
    }
    
    if (_Server.TraceInConsole)
    
        Console.WriteLine("End HttpRequest.");
    

    }

    (3)用TryCloseSocket()函数,关闭Socket

    如果直接调用Socket的Close方法会关闭得太快,可能导致客户端TIME_WAIT现象;而Thead.Sleep延时再调用Socket的Close方法也不理想。应该采用尝试向客户端发送数据,然后利用异常来关闭Socket,方法如下。

    private void TryCloseSocket()
    
    {
    try
    
    {
    
        while (true)
    
        {
    
            Thread.Sleep(1500);
    
            Send(HttpServer.BYTES_CRLF); //发送自定义的字节,如果客户端关闭出现SocketException,然后关闭服务端Socket
    
            if (_Client == null)
    
                break;
    
        }
    
    }
    
    catch (SocketException)
    
    {
    
        CloseSocket();
    
    }
    
     }
    
     
    
    private void CloseSocket()
    
    {
    if (_Client != null)
    
    {
    
        _Client.Shutdown(SocketShutdown.Both);
    
        _Client.Close();
    
        _Client = null;
    
        if (_Server.TraceInConsole)
    
        {
    
            Console.WriteLine("Close socket.");
    
        }
    
    }
    

    }

    展开全文
  • 如题,没弄懂吃了大亏。。。
    如题,没弄懂吃了大亏。。。
    展开全文
  •  ConnManagerParams.setTimeout(httpParams, WAIT_TIMEOUT);    // 设置每个路由最大连接数    ConnPerRouteBean connPerRoute =  new  ConnPerRouteBean(MAX_ROUTE_CONNECTIONS);   ...

    昨天解决了一个HttpClient调用错误导致的服务器异常,具体过程如下:

    HttpClient连接池抛出大量ConnectionPoolTimeoutException: Timeout waiting for connection异常排查

    今天解决了一个HttpClient的异常,汗啊,一个HttpClient使用稍有不慎都会是毁灭级别的啊。

    这里有之前因为route配置不当导致服务器异常的一个处理:


    HttpClient4.X 升级 入门 + http连接池使用

    在一次服务器异常的排查过程当中(服务器异常排查的过程我会另起文章),我们决定使用HttpClient4.X替代HttpClient3.X或者HttpConnection。

    为什么使用HttpClient4?主要是HttpConnection没有连接池的概念,多少次请求就会建立多少个IO,在访问量巨大的情况下服务器的IO可能会耗尽。

    HttpClient3也有连接池的东西在里头,使用MultiThreadedHttpConnectionManager,大致过程如下:

    [java]  view plain  copy
     print ?
    1. MultiThreadedHttpConnectionManager connectionManager = new MultiThreadedHttpConnectionManager();  
    2. HttpClient client = new HttpClient(connectionManager);...// 在某个线程中。  
    3. GetMethod get = new GetMethod("http://jakarta.apache.org/");  
    4. try {  
    5. client.executeMethod(get);// print response to stdout  
    6. System.out.println(get.getResponseBodyAsStream());  
    7. finally {  
    8. // be sure the connection is released back to the connection   
    9. managerget.releaseConnection();  
    10. }  

    可以看出来,它的方式与jdbc连接池的使用方式相近,我觉得比较不爽的就是需要手动调用releaseConnection去释放连接。对每一个HttpClient.executeMethod须有一个method.releaseConnection()与之匹配。

     

    HttpClient4在这点上做了改进,使用我们常用的InputStream.close()来确认连接关闭(4.1版本之前使用entity.consumeContent()来确认内容已经被消耗关闭连接)。具体方式如下:

    [java]  view plain  copy
     print ?
    1. ...HttpClient client = null;InputStream in = null;  
    2. try{  
    3. client = HttpConnectionManager.getHttpClient();  
    4. HttpGet get = new HttpGet();  
    5. get.setURI(new URI(urlPath));  
    6. HttpResponse response = client.execute(get);  
    7. HttpEntity entity =response.getEntity();  
    8. if( entity != null ){   
    9.  in = entity.getContent();  
    10.  ....  
    11. }catch (Exception e){  
    12. ....  
    13. }finally{  
    14. if (in != null){  
    15. try{in.close ();}catch (IOException e){  
    16. e.printStackTrace ();  
    17. }  
    18. }  
    19. }  

    2012-03-06更新:

    有网友提出调用in.close()是否会关闭底层socket,事情是这样的:

    [plain]  view plain  copy
     print ?
    1. 回复kangkang203:感谢你提出的这个问题。  
    2. 首先我文中提出的方法in.close()它会触发一个连接的释放这个连接将重新被连接管理器收回,官网的原文是这么说的:“Closing the input stream will trigger connection release...the underlying connection gets released back to the connection manager”。但是底层的socket是否会被关闭是不一定的,我看了部分源码(EofSensorInputStream)发现,大多数情况socket并不会关闭,而是否关闭socket貌似是由一个Watcher去决定的。所以in.close的调用不会引起socket的关闭。  
    3. 另外,由于http本身我们把它当做“短连接”,所以在一次请求交互完成后仍然打开socket的意义不是很大,毕竟它不像长连接那样在一个连接建立之后会有很多次数据交互。我们试用连接管理器的更多意义在于它对连接的管理。  

     

    好说完了连接池的使用流程,现在来说一说连接池在使用时最重要的几个参数。我用4.1的版本实现了一个简单的HttpConnectionManager,代码如下:

    [java]  view plain  copy
     print ?
    1. public class HttpConnectionManager {   
    2.   
    3.     private static HttpParams httpParams;  
    4.     private static ClientConnectionManager connectionManager;  
    5.   
    6.     /** 
    7.      * 最大连接数 
    8.      */  
    9.     public final static int MAX_TOTAL_CONNECTIONS = 800;  
    10.     /** 
    11.      * 获取连接的最大等待时间 
    12.      */  
    13.     public final static int WAIT_TIMEOUT = 60000;  
    14.     /** 
    15.      * 每个路由最大连接数 
    16.      */  
    17.     public final static int MAX_ROUTE_CONNECTIONS = 400;  
    18.     /** 
    19.      * 连接超时时间 
    20.      */  
    21.     public final static int CONNECT_TIMEOUT = 10000;  
    22.     /** 
    23.      * 读取超时时间 
    24.      */  
    25.     public final static int READ_TIMEOUT = 10000;  
    26.   
    27.     static {  
    28.         httpParams = new BasicHttpParams();  
    29.         // 设置最大连接数  
    30.         ConnManagerParams.setMaxTotalConnections(httpParams, MAX_TOTAL_CONNECTIONS);  
    31.         // 设置获取连接的最大等待时间  
    32.         ConnManagerParams.setTimeout(httpParams, WAIT_TIMEOUT);  
    33.         // 设置每个路由最大连接数  
    34.         ConnPerRouteBean connPerRoute = new ConnPerRouteBean(MAX_ROUTE_CONNECTIONS);  
    35.         ConnManagerParams.setMaxConnectionsPerRoute(httpParams,connPerRoute);  
    36.         // 设置连接超时时间  
    37.         HttpConnectionParams.setConnectionTimeout(httpParams, CONNECT_TIMEOUT);  
    38.         // 设置读取超时时间  
    39.         HttpConnectionParams.setSoTimeout(httpParams, READ_TIMEOUT);  
    40.   
    41.         SchemeRegistry registry = new SchemeRegistry();  
    42.         registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));  
    43.         registry.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));  
    44.   
    45.         connectionManager = new ThreadSafeClientConnManager(httpParams, registry);  
    46.     }  
    47.   
    48.     public static HttpClient getHttpClient() {  
    49.         return new DefaultHttpClient(connectionManager, httpParams);  
    50.     }  
    51.   
    52. }  

    最大连接数、获取连接的最大等待时间、读取超时时间 这些配置应该比较容易理解,一般的连接池都会有这些配置,比较特别的是 每个路由(route)最大连接数 。

     

    什么是一个route?

     

    这里route的概念可以理解为 运行环境机器 到 目标机器的一条线路。举例来说,我们使用HttpClient的实现来分别请求 www.baidu.com 的资源和 www.bing.com 的资源那么他就会产生两个route。

     

    这里为什么要特别提到route最大连接数这个参数呢,因为这个参数的默认值为2,如果不设置这个参数值默认情况下对于同一个目标机器的最大并发连接只有2个!这意味着如果你正在执行一个针对某一台目标机器的抓取任务的时候,哪怕你设置连接池的最大连接数为200,但是实际上还是只有2个连接在工作,其他剩余的198个连接都在等待,都是为别的目标机器服务的。

     

    怎么样蛋疼吧,我是已经有过血的教训了,在切换到HttpClient4.1的起初没有注意到这个配置,最后使得服务承受的压力反而不如从前了,所以在这里特别提醒大家注意。

     

    HttpClient4.X 教程下载:

    http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient-contrib/docs/translated-tutorial/httpclient-tutorial-simplified-chinese.pdf


    关于版本的补充:

    网友w2449008821提醒之后我才发现在HttpClient4.1+的版本ConnManagerParams已经被Deprecated了。

    我在写这篇日志的时候时候的httpclient 版本是4.0.3,从4.0版本之后ConnManagerParams被Deprecated,没想到一个小版本升级会有这么大变化。

    官网教程举例了新的连接池设置:

    [java]  view plain  copy
     print ?
    1. SchemeRegistry schemeRegistry = new SchemeRegistry();  
    2. schemeRegistry.register(  
    3.          new Scheme("http"80, PlainSocketFactory.getSocketFactory()));  
    4. schemeRegistry.register(  
    5.          new Scheme("https"443, SSLSocketFactory.getSocketFactory()));  
    6.   
    7. ThreadSafeClientConnManager cm = new ThreadSafeClientConnManager(schemeRegistry);  
    8. // Increase max total connection to 200  
    9. cm.setMaxTotalConnections(200);  
    10. // Increase default max connection per route to 20  
    11. cm.setDefaultMaxPerRoute(20);  
    12. // Increase max connections for localhost:80 to 50  
    13. HttpHost localhost = new HttpHost("locahost"80);  
    14. cm.setMaxForRoute(new HttpRoute(localhost), 50);  
    15.    
    16. HttpClient httpClient = new DefaultHttpClient(cm);  
    ConnManagerParams的功能被挪到了 ThreadSafeClientConnManager 和 HttpConnectionParams两个类:

    static ConnPerRoutegetMaxConnectionsPerRoute(HttpParams params) 
              Deprecated. use ThreadSafeClientConnManager.getMaxForRoute(org.apache.http.conn.routing.HttpRoute)
    static intgetMaxTotalConnections(HttpParams params) 
              Deprecated. use ThreadSafeClientConnManager.getMaxTotal()
    static longgetTimeout(HttpParams params) 
              Deprecated. use HttpConnectionParams.getConnectionTimeout(HttpParams)
    static voidsetMaxConnectionsPerRoute(HttpParams params, ConnPerRoute connPerRoute) 
              Deprecated. use ThreadSafeClientConnManager.setMaxForRoute(org.apache.http.conn.routing.HttpRoute, int)
    static voidsetMaxTotalConnections(HttpParams params, int maxTotalConnections) 
              Deprecated. use ThreadSafeClientConnManager.setMaxTotal(int)
    static voidsetTimeout(HttpParams params, long timeout) 
              Deprecated. use HttpConnectionParams.setConnectionTimeout(HttpParams, int)

    ——————————————————————————————

    分割线

    ——————————————————————————————


    里面的HttpConnectionManager实现就是我在这里使用的实现。


    问题表现:

    tomcat后台日志发现大量异常

    [plain]  view plain  copy
     print ?
    1. org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection  

    时间一长tomcat就无法继续处理其他请求,从假死变成真死了。

    linux运行:

    [plain]  view plain  copy
     print ?
    1. netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  
    发现CLOSE_WAIT的数量始终在400以上,一直没降过。


    问题分析:

    一开始我对我的HttpClient使用过程深信不疑,我不认为异常是来自这里。

    所以我开始从TCP的连接状态入手,猜测可能导致异常的原因。以前经常遇到TIME_WAIT数过大导致的服务器异常,很容易解决,修改下sysctl就ok了。但是这次是CLOSE_WAIT,是完全不同的概念了。

    关于TIME_WAIT和CLOSE_WAIT的区别和异常处理我会单独起一篇文章详细说说我的理解。


    简单来说CLOSE_WAIT数目过大是由于被动关闭连接处理不当导致的。

    我说一个场景,服务器A会去请求服务器B上面的apache获取文件资源,正常情况下,如果请求成功,那么在抓取完资源后服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后自己并没有释放连接,那就会造成CLOSE_WAIT的状态了。

    所以很明显,问题还是处在程序里头。


    先看看我的HttpConnectionManager实现:

    [java]  view plain  copy
     print ?
    1. public class HttpConnectionManager {   
    2.   
    3.     private static HttpParams httpParams;  
    4.     private static ClientConnectionManager connectionManager;  
    5.   
    6.     /** 
    7.      * 最大连接数 
    8.      */  
    9.     public final static int MAX_TOTAL_CONNECTIONS = 800;  
    10.     /** 
    11.      * 获取连接的最大等待时间 
    12.      */  
    13.     public final static int WAIT_TIMEOUT = 60000;  
    14.     /** 
    15.      * 每个路由最大连接数 
    16.      */  
    17.     public final static int MAX_ROUTE_CONNECTIONS = 400;  
    18.     /** 
    19.      * 连接超时时间 
    20.      */  
    21.     public final static int CONNECT_TIMEOUT = 10000;  
    22.     /** 
    23.      * 读取超时时间 
    24.      */  
    25.     public final static int READ_TIMEOUT = 10000;  
    26.   
    27.     static {  
    28.         httpParams = new BasicHttpParams();  
    29.         // 设置最大连接数  
    30.         ConnManagerParams.setMaxTotalConnections(httpParams, MAX_TOTAL_CONNECTIONS);  
    31.         // 设置获取连接的最大等待时间  
    32.         ConnManagerParams.setTimeout(httpParams, WAIT_TIMEOUT);  
    33.         // 设置每个路由最大连接数  
    34.         ConnPerRouteBean connPerRoute = new ConnPerRouteBean(MAX_ROUTE_CONNECTIONS);  
    35.         ConnManagerParams.setMaxConnectionsPerRoute(httpParams,connPerRoute);  
    36.         // 设置连接超时时间  
    37.         HttpConnectionParams.setConnectionTimeout(httpParams, CONNECT_TIMEOUT);  
    38.         // 设置读取超时时间  
    39.         HttpConnectionParams.setSoTimeout(httpParams, READ_TIMEOUT);  
    40.   
    41.         SchemeRegistry registry = new SchemeRegistry();  
    42.         registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));  
    43.         registry.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));  
    44.   
    45.         connectionManager = new ThreadSafeClientConnManager(httpParams, registry);  
    46.     }  
    47.   
    48.     public static HttpClient getHttpClient() {  
    49.         return new DefaultHttpClient(connectionManager, httpParams);  
    50.     }  
    51.   
    52. }  


    看到没MAX_ROUTE_CONNECTIONS 正好是400,跟CLOSE_WAIT非常接近啊,难道是巧合?继续往下看。

    然后看看调用它的代码是什么样的:

    [java]  view plain  copy
     print ?
    1. public static String readNet (String urlPath)  
    2.     {  
    3.         StringBuffer sb = new StringBuffer ();  
    4.         HttpClient client = null;  
    5.         InputStream in = null;  
    6.         InputStreamReader isr = null;  
    7.         try  
    8.         {  
    9.             client = HttpConnectionManager.getHttpClient();  
    10.             HttpGet get = new HttpGet();  
    11.             get.setURI(new URI(urlPath));  
    12.             HttpResponse response = client.execute(get);  
    13.             if (response.getStatusLine ().getStatusCode () != 200) {  
    14.                 return null;  
    15.             }  
    16.             HttpEntity entity =response.getEntity();  
    17.               
    18.             if( entity != null ){  
    19.                 in = entity.getContent();  
    20.                 .....  
    21.             }  
    22.             return sb.toString ();  
    23.               
    24.         }  
    25.         catch (Exception e)  
    26.         {  
    27.             e.printStackTrace ();  
    28.             return null;  
    29.         }  
    30.         finally  
    31.         {  
    32.             if (isr != null){  
    33.                 try  
    34.                 {  
    35.                     isr.close ();  
    36.                 }  
    37.                 catch (IOException e)  
    38.                 {  
    39.                     e.printStackTrace ();  
    40.                 }  
    41.             }  
    42.             if (in != null){  
    43.                 try  
    44.                 {  
    45.                     <span style="color:#ff0000;">in.close ();</span>  
    46.                 }  
    47.                 catch (IOException e)  
    48.                 {  
    49.                     e.printStackTrace ();  
    50.                 }  
    51.             }  
    52.         }  
    53.     }  

    很简单,就是个远程读取中文页面的方法。值得注意的是这一段代码是后来某某同学加上去的,看上去没啥问题,是用于非200状态的异常处理:

    [java]  view plain  copy
     print ?
    1. if (response.getStatusLine ().getStatusCode () != 200) {  
    2.                 return null;  
    3.             }  

    代码本身没有问题,但是问题是放错了位置。如果这么写的话就没问题:

    [java]  view plain  copy
     print ?
    1. client = HttpConnectionManager.getHttpClient();  
    2.             HttpGet get = new HttpGet();  
    3.             get.setURI(new URI(urlPath));  
    4.             HttpResponse response = client.execute(get);  
    5.               
    6.             HttpEntity entity =response.getEntity();  
    7.               
    8.             if( entity != null ){  
    9.                 in = entity.getContent();  
    10.             ..........  
    11.             }  
    12.               
    13.             if (response.getStatusLine ().getStatusCode () != 200) {  
    14.                 return null;  
    15.             }  
    16.             return sb.toString ();  
    看出毛病了吧。在这篇入门( HttpClient4.X 升级 入门 + http连接池使用 )里头我提到了HttpClient4使用我们常用的InputStream.close()来确认连接关闭,前面那种写法InputStream in 根本就不会被赋值,意味着一旦出现非200的连接,这个连接将永远僵死在连接池里头,太恐怖了。。。所以我们看到CLOST_WAIT数目为400,因为对一个路由的连接已经完全被僵死连接占满了。。。

    其实上面那段代码还有一个没处理好的地方,异常处理不够严谨,所以最后我把代码改成了这样:

    [java]  view plain  copy
     print ?
    1. public static String readNet (String urlPath)  
    2.     {  
    3.         StringBuffer sb = new StringBuffer ();  
    4.         HttpClient client = null;  
    5.         InputStream in = null;  
    6.         InputStreamReader isr = null;  
    7.         HttpGet get = new HttpGet();  
    8.         try  
    9.         {  
    10.             client = HttpConnectionManager.getHttpClient();  
    11.             get.setURI(new URI(urlPath));  
    12.             HttpResponse response = client.execute(get);  
    13.             if (response.getStatusLine ().getStatusCode () != 200) {  
    14.                 get.abort();  
    15.                 return null;  
    16.             }  
    17.             HttpEntity entity =response.getEntity();  
    18.               
    19.             if( entity != null ){  
    20.                 in = entity.getContent();  
    21.                 ......  
    22.             }  
    23.             return sb.toString ();  
    24.               
    25.         }  
    26.         catch (Exception e)  
    27.         {  
    28.             get.abort();  
    29.             e.printStackTrace ();  
    30.             return null;  
    31.         }  
    32.         finally  
    33.         {  
    34.             if (isr != null){  
    35.                 try  
    36.                 {  
    37.                     isr.close ();  
    38.                 }  
    39.                 catch (IOException e)  
    40.                 {  
    41.                     e.printStackTrace ();  
    42.                 }  
    43.             }  
    44.             if (in != null){  
    45.                 try  
    46.                 {  
    47.                     in.close ();  
    48.                 }  
    49.                 catch (IOException e)  
    50.                 {  
    51.                     e.printStackTrace ();  
    52.                 }  
    53.             }  
    54.         }  
    55.     }  

    显示调用HttpGet的abort,这样就会直接中止这次连接,我们在遇到异常的时候应该显示调用,因为谁能保证异常是在InputStream in赋值之后才抛出的呢。


    好了 ,分析完毕,明天准备总结下CLOSE_WAIT和TIME_WAIT的区别。

    ————————————————————————————————————————

    分割线

    ————————————————————————————————————————

    里头的分析过程有提到,通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。

    在服务器的日常维护过程中,会经常用到下面的命令:

    [plain]  view plain  copy
     print ? 在CODE上查看代码片 派生到我的代码片
    1. netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'    

    它会显示例如下面的信息:

    TIME_WAIT 814
    CLOSE_WAIT 1
    FIN_WAIT1 1
    ESTABLISHED 634
    SYN_RECV 2
    LAST_ACK 1

    常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。


    具体每种状态什么意思,其实无需多说,看看下面这种图就明白了,注意这里提到的服务器应该是业务请求接受处理的一方:



    这么多状态不用都记住,只要了解到我上面提到的最常见的三种状态的意义就可以了。一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况:

    1.服务器保持了大量TIME_WAIT状态

    2.服务器保持了大量CLOSE_WAIT状态

    因为linux分配给一个用户的文件句柄是有限的(可以参考:http://blog.csdn.net/shootyou/article/details/6579139),而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,tomcat崩溃。。。

    下面来讨论下这两种情况的处理方法,网上有很多资料把这两种情况的处理方法混为一谈,以为优化系统内核参数就可以解决问题,其实是不恰当的,优化系统内核参数解决TIME_WAIT可能很容易,但是应对CLOSE_WAIT的情况还是需要从程序本身出发。现在来分别说说这两种情况的处理方法:


    1.服务器保持了大量TIME_WAIT状态

    这种情况比较常见,一些爬虫服务器或者WEB服务器(如果网管在安装的时候没有做内核参数优化的话)上经常会遇到这个问题,这个问题是怎么产生的呢?

    从上面的示意图可以看得出来,TIME_WAIT是主动关闭连接的一方保持的状态,对于爬虫服务器来说他本身就是“客户端”,在完成一个爬取任务之后,他就会发起主动关闭连接,从而进入TIME_WAIT的状态,然后在保持这个状态2MSL(max segment lifetime)时间之后,彻底关闭回收资源。为什么要这么做?明明就已经主动关闭连接了为啥还要保持资源一段时间呢?这个是TCP/IP的设计者规定的,主要出于以下两个方面的考虑:

    1.防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)
    2.可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。

    关于MSL引用下面一段话:

    [plain]  view plain  copy
     print ? 在CODE上查看代码片 派生到我的代码片
    1. MSL 為一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間),由於 RFC 793 TCP 傳輸協定是在 1981 年定義的,當時的網路速度不像現在的網際網路那樣發達,你可以想像你從瀏覽器輸入網址等到第一個 byte 出現要等 4 分鐘嗎?在現在的網路環境下幾乎不可能有這種事情發生,因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低,好讓 連線埠 (Ports) 能更快空出來給其他連線使用。  

    再引用网络资源的一段话:

    [plain]  view plain  copy
     print ? 在CODE上查看代码片 派生到我的代码片
    1. 值得一说的是,对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可 想而知,对于访问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压240*1000=240,000个 TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT,所以对于新的 TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。  
    2. HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个 request/response,一个主要原因就是发现了这个问题。  

    也就是说HTTP的交互跟上面画的那个图是不一样的,关闭连接的不是客户端,而是服务器,所以web服务器也是会出现大量的TIME_WAIT的情况的。

    现在来说如何来解决这个问题。

    解决思路很简单,就是让服务器能够快速回收和重用那些TIME_WAIT的资源。

    下面来看一下我们网管对/etc/sysctl.conf文件的修改:
    [plain]  view plain  copy
     print ? 在CODE上查看代码片 派生到我的代码片
    1. #对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间   
    2. net.ipv4.tcp_syn_retries=2  
    3. #net.ipv4.tcp_synack_retries=2  
    4. #表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒  
    5. net.ipv4.tcp_keepalive_time=1200  
    6. net.ipv4.tcp_orphan_retries=3  
    7. #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间  
    8. net.ipv4.tcp_fin_timeout=30    
    9. #表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。  
    10. net.ipv4.tcp_max_syn_backlog = 4096  
    11. #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭  
    12. net.ipv4.tcp_syncookies = 1  
    13.   
    14. #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭  
    15. net.ipv4.tcp_tw_reuse = 1  
    16. #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭  
    17. net.ipv4.tcp_tw_recycle = 1  
    18.   
    19. ##减少超时前的探测次数   
    20. net.ipv4.tcp_keepalive_probes=5   
    21. ##优化网络设备接收队列   
    22. net.core.netdev_max_backlog=3000   
    [plain]  view plain  copy
     print ?
    1.   

    修改完之后执行/sbin/sysctl -p让参数生效。

    这里头主要注意到的是 net.ipv4.tcp_tw_reuse
    net.ipv4.tcp_tw_recycle
    net.ipv4.tcp_fin_timeout
    net.ipv4.tcp_keepalive_*
    这几个参数。

    net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。
    net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。
    net.ipv4.tcp_keepalive_*一系列参数,是用来设置服务器检测连接存活的相关配置。

    [2015.01.13更新]
    注意tcp_tw_recycle开启的风险:http://blog.csdn.net/wireless_tech/article/details/6405755

    2.服务器保持了大量CLOSE_WAIT状态
    休息一下,喘口气,一开始只是打算说说TIME_WAIT和CLOSE_WAIT的区别,没想到越挖越深,这也是写博客总结的好处,总可以有意外的收获。

    TIME_WAIT状态可以通过优化服务器参数得到解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。
    但是CLOSE_WAIT就不一样了,从上面的图可以看出来,如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直被程序占着。个人觉得这种情况,通过服务器内核参数也没办法解决,服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。

    如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情况,那么这篇日志也许对你有用:http://blog.csdn.net/shootyou/article/details/6615051
    在那边日志里头我举了个场景,来说明CLOSE_WAIT和TIME_WAIT的区别,这里重新描述一下:
    服务器A是一台爬虫服务器,它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源,正常情况下,如果请求成功,那么在抓取完资源后,服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后程序员忘了让HttpClient释放连接,那就会造成CLOSE_WAIT的状态了。

    所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是:查代码。因为问题出在服务器程序里头啊。

    展开全文
  • 使用 Task.Wait()死锁

    千次阅读 2018-12-14 08:47:47
    wait线程锁:主执行线程调用子线程后挂起等待子线程结果,子线程又需要切换到主线程或者等待主线程返回,从而导致两个线程均处在阻塞状态(死锁) 调用 Task.Wait() 或者 Task.Result 立刻产生死锁的充分条件:...

    转:https://blog.csdn.net/wpwalter/article/details/78370706

     

    原文一部分内容:

    wait线程锁:主执行线程调用子线程后挂起等待子线程结果,子线程又需要切换到主线程或者等待主线程返回,从而导致两个线程均处在阻塞状态(死锁)

    调用 Task.Wait() 或者 Task.Result 立刻产生死锁的充分条件: 
    1. 调用 Wait() 或 Result 的代码位于 UI 线程; 
    2. Task 的实际执行在其他线程。

    总结不会造成死锁的充分条件: 
    1. 异步操作执行完后不需要回到原有线程(例如非 UI 线程和控制台线程); 
    2. 异步操作不需要单独的线程执行任务。

    如何避免死锁?

    明确了会造成死锁的条件和不会造成死锁的条件后,我们只需要做到以下几点即可避免死锁了:

    在 UI 线程,如果使用了 async/await,就尽量不要再使用 Task.Wait()/Task.Result 了,就一直异步一条路走到黑好了(微软称其为 Async All the Way)。
    如果可能,尽量在异步任务后添加 .ConfigureAwait(false);这样,异步任务后面继续执行的代码就不会回到原 UI 线程了,而是直接从线程池中再取出一个线程执行;这样,即便 UI 线程后续可能有别的原因造成阻塞,也不会产生死锁了
    把原来的代码改成这样,就不会死锁了:

    await DoAsync();

    async Task DoAsync()
    {
        await Task.Run(() => { });
    }

    没错!只能是一路 async/await。微软将其描述为:async/await 会像病毒一样在你的代码中传播。

    Others have also noticed the spreading behavior of asynchronous programming and have called it “contagious” or compared it to a zombie virus.
    这句话的原文参见:Async/Await - Best Practices in Asynchronous Programming

    为了防止真的有代码的调用者使用 Wait(),我们也得写出防 SB 的代码来:

    async Task DoAsync()
    {
        await Task.Run(() => { }).ConfigureAwait(false);
    }
     

    展开全文
  • 使用 Task.Wait()?立刻死锁(deadlock)

    千次阅读 2017-10-27 23:59:35
    最近读到一篇异步转同步的文章,发现其中没有考虑到异步转同步过程中发生的死锁问题,所以特地在...调用 Task.Wait() 或者 Task.Result 立刻产生死锁的充分条件: 1. 调用 Wait() 或 Result 的代码位于 UI 线程;...
  • Close_wait异常排查

    2019-04-24 23:46:49
    但近日看到一篇文章,描述了close_wait异常的可能情况,觉得讲的很好,而且提前注意这一点,以后遇到异常就多一个方向,能更快的排查异常,故记录此文,防止自己以后埋个大坑。 参考链接 问题表现: tomcat后台日志...
  • ====== LINUX ====== 通过调整内核参数解决 vi /etc/sysctl.conf 编辑文件,加入以下内容: net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 ...然后执行/sb
  • Java Process中waitFor()的问题

    万次阅读 2012-04-16 17:30:01
    这个对象中的waitFor()是我们今天要讨论的重点。  来说说我遇到的实际情况:我想调用ffmpeg程序来对一首歌曲进行转码,把高音质版本的歌曲转为多种低码率的文件。但是在转码完成之后需要做以下操作:读取文件...
  • 2020-06-29T23:04:20.245804+08:00 0 [Warning] InnoDB: A long semaphore wait: --Thread 140585006524160 has waited at trx0purge.cc line 154 for 241 seconds the semaphore: Mutex at 0x37045c0, Mutex REDO...
  • Process#waitFor()阻塞问题

    千次阅读 2019-04-02 20:01:15
         有时需要在程序中调用...int exitCode = process .waitFor();   Runtime.getRuntime()返回当前应用程序的Runtime对象,该对象的exec()方法指示Java虚拟机创建一个子进程执行指定的可执行程序,并返回与...
  • HttpClient 与 Close_Wait

    2016-01-26 13:25:00
    服务器A需要通过HttpClient去连接另一个系统B提供的服务,运行一段时间后抛出以下异 常:java.net.SocketException: Connection reset by peer: socket write error close_wait 在服务器B上运行netstat命令,...
  • 因为该bash操作耗时比较长,所以使用了Process.waitFor()去等待子线程运行结束。 这个时候发现程序卡在waitFor()没有继续往下执行。 看了官方解释: waitFor:等待子进程执行结束,或者已终止子进程,此方法立即...
  • oracle的等待事件针对的就是被阻塞态(当然也许是它的一个很大的一个子集,但不是全集),也就是说这时会话在waiting,如果这个时候你查询v$session_wait,STATE=WAITING,SECONDS_IN_WAIT表示已经等待的时间(误差是3秒),...
  • 使用wait()与notifyAll()实现生产者与消费者模式 所涉及到的基础知识 wait() 一、wait是java同步机制中重要的组成部分。结合与synchronized关键字使用,否则运行时会收到一个异常:...
  • 在编写Java程序时,有时候我们需要调用其他的诸如exe,shell这样的程序或脚本。在Java中提供了两种方法来启动其他程序: (1) 使用Runtime的exec()方法 ...这个对象中的waitFor()是我们今天要讨...
  • 1、发现问题 在实际开发中,进行文件操作时,使用Process对文件进行解压操作,程序执行...假设该程序不断在向标准输出流和标准错误流写数据,而JVM不读取的话,当缓冲区满之后将无法继续写入数据,最终造成阻塞在wait
  • process.waitfor()发生阻塞

    千次阅读 2016-10-25 17:17:29
    在Java编写应用时,有时需要在程序中调用另...ps.waitfor(); Runtime.getRuntime()返回当前应用程序的Runtime对象,该对象的exec()方法指示Java虚拟机创建一个子进程执行指定的可执行程序, 并返回与该子进程对应的Pr
  • 在线线程中调用wait方法的时候 要用synchronized锁住对象,确保代码段不会被多个线程调用。加上了synchronized解决了次异常;
  • java process的waitfor()阻塞问题

    千次阅读 2016-11-24 15:33:48
    Runtime runtime = Runtime.getRuntime(); Process proc = runtime.exec(COMMAND2_SSH); proc.waitFor() //容易造成主线程的阻塞。 原因: 当执行exec()后,创建一个
  • 1.wait()与notify()/notifyAll()   调用sleep()和yield()的时候锁并没有被释放,而调用wait()将释放锁。这样另一个任务(线程)可以获得当前对象的锁,从而进入它的synchronized方法中。可以通过notify()/...
  • oracle wait events(等待事件) 一览表

    千次阅读 2015-04-16 23:00:35
    在oracle出现性能问题时,通过等待事件,非常有助于我们去分析问题。在oracle的每个大的版本里面,都会增加或者删除一些等待事件。... 我们可以通过查询v$event_name查看所有的等待事件(wait eve...
  • Java Object中wait()和notify()小议

    千次阅读 2014-06-24 07:29:09
    sb.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } } } } 在最后,wait()方法有两个重载的方法,他们的作用是让线程阻塞特定时间后还没有获得notify的通知,自动自己...
  • Ext.Msg.wait()用法

    千次阅读 2012-10-26 09:55:45
    1在数据请求开始  Ext.Msg.wait("温馨提示:蓝色连通,红色异常!","数据初始化......");  Ext.Ajax.request({  url : baseP
  • 文件系统中经常会有wait_on_page_bit函数的封装,比如f2fs中就会有如下的代码: 1431 void f2fs_wait_on_page_writeback(struct page *page, //等待页写回.1432 enum page_type type)1433 {1434 if (PageWriteback...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 14,359
精华内容 5,743
关键字:

sbwait