Thread security scenario memo

 

 

Thread security scenario memo:

1. Delayed loading of thread problems caused by loading-Use of delayed loading of Singleton (some Singleton implementations do not require delayed loading)-avoid the thread from instantiating the domain multiple times and only instantiating the domain once

2. thread security issues for static domains with non-delayed loading: multi-threaded modification of domain attribute values. Note that this example does not address scenario 1. Because the domain is static and non-delayed, and the domain is private, this domain will be instantiated only once.

 

Public class Weibo implements java. Io. serializable {

Private Static final long serialversionuid = 4282616848978535016l;
// Static domain. The starting point is good. After all, it is too waste of resources to instantiate an httpclient. The problem is that the token of the client is not thread-safe.
// Solution: 1) Each Weibo Request Code should be encapsulated with settoken to ensure atomicity. This requires many ways to use the inefficient synchronized.
// 2). The accesen en in httpclient is defined as threadlocal instead of synchronizing the client code. Note that you do not need to modify the API source code to synchronize the code in httpclient. This internal synchronization is not a reasonable alternative to external synchronization. Because the granularity is different. If the code called by the client is only synchronized to the settoken method, the client code can be avoided and synchronized to the API.
Public static httpclient client = new httpclient ();

Public void settoken (string token ){
Client. settoken (token );
}

}

3. Pseudo-thread security problem: Some attributes of daodaosnsweiboservice only need to be initialized at a time and require atomicity. This is a pseudo-multithreading problem as required. Multiple Threads do not use updateproperties.

Public class daodaosnsweiboservice implements idaodaosnssvc {

.....
// Use non-delayed loading for static domain initialization.
Static {
Final string client_id = "*******";
Final string client_sercret = "******************";
Final string baseurl = "https://api.weibo.com/2 ";
Final string accesstokenurl = "https://api.weibo.com/2/oauth2/access_token ";
Final string authorizeurl = "https://api.weibo.com/2/oauth2/authorize ";
// Weiboconfig is initialized only once, while httpclient sets the value of the attribute accesstoken every time. This scenario determines. The prop attribute in webconfig should not be threadlocal.
// Weiboconfig is not necessary for internal synchronization, because the client code does not call sync for each updateproperties method in fine granularity. If the client code is synchronized multiple times, you can consider internal synchronization. In addition, whether the exposed updateproperties are reasonable remains to be discussed. I feel that we should export a method to modify attributes in batches. This fine-grained method has no external significance. In addition, the customer code must be synchronized externally to ensure the integrity of batch modifications.
// Because the initialization is performed only once, the following synchronized can be removed.
Synchronized (daodaosnsweiboservice. Class ){
Weiboconfig. updateproperties ("client_id", client_id );
Weiboconfig. updateproperties ("client_sercret", client_sercret );
Weiboconfig. updateproperties ("baseurl", baseurl );
Weiboconfig. updateproperties ("accesstokenurl", accesstokenurl );
Weiboconfig. updateproperties ("authorizeurl", authorizeurl );
}
};

.....

}