生产问题排查与程序设计的一些思考

来源:互联网 发布:关于网络组建的论文 编辑:程序博客网 时间:2024/05/20 11:52

最近处理生产上的一些问题,对程序设计和编程有了一些新的认识。浅谈一下。

1、Servlet

servlet这个东西,可以用来做对外服务的接口,发布一个上下文就可以使用http调用。也许很多时间我们只是简单地override了doGet和doPost方法,调用业务处理完print回去。如果这个业务处理很费时,那么这个servlet线程就会一直不能回收。我们知道一个tomcat能接受的最大并发是有限的。所以如果servlet容器资源用尽,很难接收后续的http请求。servlet 3.0的新特性async-supported帮我们解决了这个事。它允许我们把servlet线程的业务处理给线程池去做,自身可以马上返回servlet池中。当子线程处理完业务后,再用持有的respone对象输出实际的响应。


2、主线程与子线程

程序使用了httpClient工具,最近发现ajax经常出现java.net.SocketTimeoutException: Read timed out,查了这个请求,是调用应用的一个接口。一开始总是以为可能是网络因素导致超时什么的。看了超时时间,设了10s,够长了,还是会出现。经验丰富的宋工说,看是不是该请求的链过长导致响应慢。有理,查之。发现方法里有一处地方使用HttpClient调用了另一个系统的接口,而这个接口里,有调用中间件写数据库和调用微信接口的操作。所有的代码都是同步的,意味着哪一个地方处理费时,就会导致最开始那个ajax的响应慢甚至超时。

所以啊,设计程序时,要充分知道哪些地方是可能会耗时长的,比如大IO读写,远程调用,读写数据库等等。这些地方,最好是启用单独的线程处理。对于需要返回值的,可以用

Future。如下代码。heavyWork()会做很费时的操作,我们用的一个Future来代替他,主线程中可以asyncGetUser(),把Future引用存在map中,这样主线程可以在其他地方通过future.get()获取到结果,而不是卡在这里。
另外提点建议,程序中一些重要的业务处理,应该针对性地输出执行时间来,比如超过多少秒的,要打印出来,这样出问题好找。
public Future<User> asyncGetUser() {    Future<User> future = threadPool.submit(new Callable<User> {        public User call() throws Exception {            return heavyWork();        }    }        return future;}

3、推送
项目二期客户需要一个推送的 功能。坐席通过在线客服给客户的券商app推送一些消息。这东西不像 IM 那样经常会有数据传输,可能是不定时才会有一两个消息,所以让app一直保持一个socket连接不好,当然这个功能可以已方来做。现在也有很多成熟的推送产品,如百度云,极光等。他们会提供一个要集成到app的sdk,开发用的jar包,一套api,帐号和地址等等。sdk的onNotificationClicked会监测到点击行为并跳转到指定的activity。用户的app是没有集成推送软件的。还有一点是现在的推送产品也是很多,都提供了简单的集成方式和开发要求,也稳定高效,比自己实现好得多。


原创粉丝点击