前几天博客搬家时，本来搬家是因为buyvm的vps不稳定，老是offline，直到昨天才发现原来是博客被人黑了。

被人挂上了后门用于发送垃圾邮件，导致CPU负载猛增服务掉线。找到问题就好办了，搜索所有的代码，把有嫌疑的文件全部干掉，删除不用的主题和插件。分析访问日志查到POST方式请求的文件删除。把不该有写入权限的文件夹去除写入权限，并修改ssh密码等。

去年也发现一个事，域名被人劫持了。现到在百度上都有一些乱七八糟的信息。

看来安全问题还是得注意了。

Java代码  

1. HttpClient client = new HttpClient();
2. HttpMethod method = new GetMethod(“http://www.apache.org”);
3. try {
4.   client.executeMethod(method);
5.   byte[] responseBody = null;
7.   responseBody = method.getResponseBody();
9. } catch (HttpException e) {
10.   // TODO Auto-generated catch block
11.   e.printStackTrace();
12. } catch (IOException e) {
13.   // TODO Auto-generated catch block
14.   e.printStackTrace();
15. }finally{
16.   method.releaseConnection();
18. }

大部分人使用HttpClient都是使用类似上面的事例代码，包括Apache官方的例子也是如此。最近我在使用HttpClient是发现一次循环发送大量请求到服务器会导致APACHE服务器的链接被占满，后续的请求便排队等待。
我服务器端APACHE的配置

Java代码  

1. Timeout 30
2. KeepAlive On   #表示服务器端不会主动关闭链接
3. MaxKeepAliveRequests 100
4. KeepAliveTimeout 180

因此这样的配置就会导致每个链接至少要过180S才会被释放，这样在大量请求访问时就必然会造成链接被占满，请求等待的情况。
在通过DEBUH后发现HttpClient在method.releaseConnection()后并没有把链接关闭，这个方法只是将链接返回给connection manager。如果使用HttpClient client = new HttpClient()实例化一个HttpClient connection manager默认实现是使用SimpleHttpConnectionManager。SimpleHttpConnectionManager有个构造函数如下

Java代码  

1. /**
2.  * The connection manager created with this constructor will try to keep the
3.  * connection open (alive) between consecutive requests if the alwaysClose
4.  * parameter is set to <tt>false</tt>. Otherwise the connection manager will
5.  * always close connections upon release.
6.  *
7.  * @param alwaysClose if set <tt>true</tt>, the connection manager will always
8.  *    close connections upon release.
9.  */
10. public SimpleHttpConnectionManager(boolean alwaysClose) {
11.     super();
12.     this.alwaysClose = alwaysClose;
13. }

看方法注释我们就可以看到如果alwaysClose设为true在链接释放之后connection manager 就会关闭链。在我们HttpClient client = new HttpClient()这样实例化一个client时connection manager是这样被实例化的

Java代码  

1. this.httpConnectionManager = new SimpleHttpConnectionManager();

因此alwaysClose默认是false,connection是不会被主动关闭的，因此我们就有了一个客户端关闭链接的方法。
方法一：
把事例代码中的第一行实例化代码改为如下即可，在method.releaseConnection();之后connection manager会关闭connection 。

Java代码  

1. HttpClient client = new HttpClient(new HttpClientParams(),new SimpleHttpConnectionManager(true) );

方法二：
实例化代码使用：HttpClient client = new HttpClient();
在method.releaseConnection();之后加上

Java代码  

1. ((SimpleHttpConnectionManager)client.getHttpConnectionManager()).shutdown();

shutdown源代码很简单，看了一目了然

Java代码  

1. public void shutdown() {
2.     httpConnection.close();
3. }

方法三：
实例化代码使用：HttpClient client = new HttpClient();
在method.releaseConnection();之后加上
client.getHttpConnectionManager().closeIdleConnections(0);此方法源码代码如下：

Java代码  

1. public void closeIdleConnections(long idleTimeout) {
2.     long maxIdleTime = System.currentTimeMillis() – idleTimeout;
3.     if (idleStartTime <= maxIdleTime) {
4.         httpConnection.close();
5.     }
6. }

将idleTimeout设为0可以确保链接被关闭。
以上这三种方法都是有客户端主动关闭TCP链接的方法。下面再介绍由服务器端自动关闭链接的方法。
方法四：
代码实现很简单，所有代码就和最上面的事例代码一样。只需要在HttpMethod method = new GetMethod(“http://www.apache.org”);加上一行HTTP头的设置即可

Java代码  

1. method.setRequestHeader(“Connection”, “close”);

看一下HTTP协议中关于这个属性的定义：
HTTP/1.1 defines the “close” connection option for the sender to signal that the connection will be closed after completion of the response. For example,
Connection: close
现在再说一下客户端关闭链接和服务器端关闭链接的区别。如果采用客户端关闭链接的方法，在客户端的机器上使用netstat –an命令会看到很多TIME_WAIT的TCP链接。如果服务器端主动关闭链接这中情况就出现在服务器端。
参考WIKI上的说明http://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions
The TIME_WAIT state is a protection mechanism in TCP. The side that closes a socket connection orderly will keep the connection in state TIME_WAIT for some time, typically between 1 and 4 minutes.
TIME_WAIT的状态会出现在主动关闭链接的这一端。TCP协议中TIME_WAIT状态主要是为了保证数据的完整传输。具体可以参考此文档：
http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html#ss2.7
另外强调一下使用上面这些方法关闭链接是在我们的应用中明确知道不需要重用链接时可以主动关闭链接来释放资源。如果你的应用是需要重用链接的话就没必要这么做，使用原有的链接还可以提供性能。

来往与微信大火拼啦，请关注我厂来往

http://laiwang.com

子线程更新UI会发生android.view.ViewRoot$CalledFromWrongThreadException异常的解决方法

子线程更新UI

显然假如你的程序需要执行耗时的操作的话，假如像上例一样由主线程来负责执行该操作是错误的。所以我们需要在onClick方法中创建一个新的子线程来负责调用GOOGLE API来获得天气数据。刚接触Android的开发者最轻易想到的方式就是如下：

public void onClick(View v) {

//创建一个子线程执行耗时的从网络上获得天气信息的操作

new Thread() {

@Override

public void run() {

//获得用户输入的城市名称

String city = editText.getText().toString();

//调用Google 天气API查询指定城市的当日天气情况

String weather = getWetherByCity(city);

//把天气信息显示在title上

setTitle(weather);

}

}.start();

}

但是很不幸，你会发现Android会提示程序由于异常而终止。为什么在其他平台上看起来很简单的代码在Android上运行的时候依然会出错呢？假如你观察LogCat中打印的日志信息就会发现这样的错误日志：

android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.

从错误信息不难看出Android禁止其他子线程来更新由UI thread创建的试图。本例中显示天气信息的title实际是就是一个由UI thread所创建的TextView，所以参试在一个子线程中去更改TextView的时候就出错了。这显示违反了单线程模型的原则：Android UI操作并不是线程安全的并且这些操作必须在UI线程中执行

2.2 Message Queue

在单线程模型下，为了解决类似的问题，Android设计了一个Message Queue(消息队列)，线程间可以通过该Message Queue并结合Handler和Looper组件进行信息交换。下面将对它们进行分别介绍：

l Message Queue

Message Queue是一个消息队列，用来存放通过Handler发布的消息。消息队列通常附属于某一个创建它的线程，可以通过Looper.myQueue()得到当前线程的消息队列。Android在第一启动程序时会默认会为UI thread创建一个关联的消息队列，用来管理程序的一些上层组件，activities，broadcast receivers 等等。你可以在自己的子线程中创建Handler与UI thread通讯。

l Handler

通过Handler你可以发布或者处理一个消息或者是一个Runnable的实例。没个Handler都会与唯一的一个线程以及该线程的消息队列管理。当你创建一个新的Handler时候，默认情况下，它将关联到创建它的这个线程和该线程的消息队列。也就是说，假如你通过Handler发布消息的话，消息将只会发送到与它关联的这个消息队列，当然也只能处理该消息队列中的消息。

主要的方法有：

1)   public final boolean sendMessage(Message msg)

把消息放入该Handler所关联的消息队列，放置在所有当前时间前未被处理的消息后。

2)   public void handleMessage(Message msg)

关联该消息队列的线程将通过调用Handler的handleMessage方法来接收和处理消息，通常需要子类化Handler来实现handleMessage。

l Looper

Looper扮演着一个Handler和消息队列之间通讯桥梁的角色。程序组件首先通过Handler把消息传送给Looper，Looper把消息放入队列。Looper也把消息队列里的消息广播给所有的Handler，Handler接受到消息后调用handleMessage进行处理。

1)   可以通过Looper类的静态方法Looper.myLooper得到当前线程的Looper实例，假如当前线程未关联一个Looper实例，该方法将返回空。

2)   可以通过静态方法Looper. getMainLooper方法得到主线程的Looper实例

线程，消息队列，Handler，Looper之间的关系可以通过一个图来展现：

在了解了消息队列及其相关组件的设计思想后，我们将把天气预告的案例通过消息队列来重新实现：

在了解了消息队列及其相关组件的设计思想后，我们将把天气预告的案例通过消息队列来重新实现：

private EditText editText;

private Handler messageHandler;

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

editText = (EditText) findViewById(R.id.weather_city_edit);

Button button = (Button) findViewById(R.id.goQuery);

button.setOnClickListener(this);

//得到当前线程的Looper实例，由于当前线程是UI线程也可以通过Looper.getMainLooper()得到

Looper looper = Looper.myLooper();

//此处甚至可以不需要设置Looper，因为 Handler默认就使用当前线程的Looper

messageHandler = new MessageHandler(looper);

}

 

@Override

public void onClick(View v) {

//创建一个子线程去做耗时的网络连接工作

new Thread() {

@Override

public void run() {

//活动用户输入的城市名称

String city = editText.getText().toString();

//调用Google 天气API查询指定城市的当日天气情况

String weather = getWetherByCity(city);

//创建一个Message对象，并把得到的天气信息赋值给Message对象

Message message = Message.obtain();

message.obj = weather;

//通过Handler发布携带有天气情况的消息

messageHandler.sendMessage(message);

}

}.start();

}

 

//子类化一个Handler

class MessageHandler extends Handler {

public MessageHandler(Looper looper) {

super(looper);

}

@Override

public void handleMessage(Message msg) {

//处理收到的消息，把天气信息显示在title上

setTitle((String) msg.obj);

}

}

通过消息队列改写过后的天气预告程序已经可以成功运行，因为Handler的handleMessage方法实际是由关联有该消息队列的UI thread调用，而在UI thread中更新title并没有违反Android的单线程模型的原则。