多线程开发的总结(别人总结的^_^)
来源:互联网 发布:短信恢复软件注册码 编辑:程序博客网 时间:2024/05/16 01:55
今年真的是郁闷透顶了。项目组居然叫我去做我从来没有做过的接口方面的编程,搞得我焦头烂额。
因为没有经验,写的代码乱七八糟,出了好多问题,不过,也学了不少东西。
首先就是Socket的编程,我只是在学习JAVA时写了一些socket方面的例子,从来就没有仔细研究过,组长居然叫我设计一个JAVA的接口平台。胡弄了一通之后,系统上线了。但是问题就来了。
首先第一个问题,长连接必须有心跳。因为之前协议中没有定义心跳协议,而我又没有经验,所以等真正上线之后才发现,如果长连接没有心跳,很容易导致在Socket连接中,长时间没有通讯的话,就会导致连接虽然保持,但不能正常通讯的问题。
第二个问题,必须加入流量控制。这个问题出现在业务高峰期时,会接收到大量请求,这时业务系统的处理速度跟不上请求发起方,导致大量请求积压在Socket服务器端,导致JVM崩溃。这个问题我之前是使用了JAVA5中所带的ExecutorService,通过设置固定的线程池数量的方式做流量控制,后来发现不行,线程会不断增加,导致JVM崩溃。不知道是我代码问题还是ExecutorService本身的问题。建议使用BlockingQueue来做队列,我目前用起来还是比较稳定。
第三个问题,是由上面的问题衍生出来的一个问题,就是效率问题。我之前的线程处理方式是每接到一个请求,会在主线程实例化一个线程实例,再把线程放到线程池中运行,这个方式除了导致上面的问题以外,而且效率很慢,我称之为“推”的方式。现在经过改良后,在服务起来之后,先事先运行固定数量的线程,然后所有线程都从同一个BlockingQueue中获取指令,我称之为“拉”的方式。这种方式让程序效率提高了很多,省去了每次生成对象的过程。而且这个设计本身也实现了处理量的控制。
第四个问题,就是指令的返回问题。在处理每个异步指令的过程时,对于返回指令,通常的做法是将返回结果指令放入队列中,然后再逐一返回。这个做法就存在了一个隐患,就是当服务器的进程core掉,或者因其它原因中断,所有的返回指令都会丢失。建议的做法是在得到返回指令之后,将要返回的结果指令持久化,通常是放入数据表或者缓存文件中,然后再操作,这样的话,当重启进程,也可以重新读取返回指令,最大可能保证接口的数据准确性。
第五个问题,其实跟上面有一些接近,就是做接口程序,有一个大原则,就是一切有迹可寻。在受理时要写日志,执行业务时要记录、返回结果时要入库。总之让运维人员可以很方便的定位问题,排除问题。否则,只能麻烦自己啦!
至于其它错误我就不一一罗列了,总之在错误中进步,还是学到不少知识。呵呵~~
因为没有经验,写的代码乱七八糟,出了好多问题,不过,也学了不少东西。
首先就是Socket的编程,我只是在学习JAVA时写了一些socket方面的例子,从来就没有仔细研究过,组长居然叫我设计一个JAVA的接口平台。胡弄了一通之后,系统上线了。但是问题就来了。
首先第一个问题,长连接必须有心跳。因为之前协议中没有定义心跳协议,而我又没有经验,所以等真正上线之后才发现,如果长连接没有心跳,很容易导致在Socket连接中,长时间没有通讯的话,就会导致连接虽然保持,但不能正常通讯的问题。
第二个问题,必须加入流量控制。这个问题出现在业务高峰期时,会接收到大量请求,这时业务系统的处理速度跟不上请求发起方,导致大量请求积压在Socket服务器端,导致JVM崩溃。这个问题我之前是使用了JAVA5中所带的ExecutorService,通过设置固定的线程池数量的方式做流量控制,后来发现不行,线程会不断增加,导致JVM崩溃。不知道是我代码问题还是ExecutorService本身的问题。建议使用BlockingQueue来做队列,我目前用起来还是比较稳定。
第三个问题,是由上面的问题衍生出来的一个问题,就是效率问题。我之前的线程处理方式是每接到一个请求,会在主线程实例化一个线程实例,再把线程放到线程池中运行,这个方式除了导致上面的问题以外,而且效率很慢,我称之为“推”的方式。现在经过改良后,在服务起来之后,先事先运行固定数量的线程,然后所有线程都从同一个BlockingQueue中获取指令,我称之为“拉”的方式。这种方式让程序效率提高了很多,省去了每次生成对象的过程。而且这个设计本身也实现了处理量的控制。
第四个问题,就是指令的返回问题。在处理每个异步指令的过程时,对于返回指令,通常的做法是将返回结果指令放入队列中,然后再逐一返回。这个做法就存在了一个隐患,就是当服务器的进程core掉,或者因其它原因中断,所有的返回指令都会丢失。建议的做法是在得到返回指令之后,将要返回的结果指令持久化,通常是放入数据表或者缓存文件中,然后再操作,这样的话,当重启进程,也可以重新读取返回指令,最大可能保证接口的数据准确性。
第五个问题,其实跟上面有一些接近,就是做接口程序,有一个大原则,就是一切有迹可寻。在受理时要写日志,执行业务时要记录、返回结果时要入库。总之让运维人员可以很方便的定位问题,排除问题。否则,只能麻烦自己啦!
至于其它错误我就不一一罗列了,总之在错误中进步,还是学到不少知识。呵呵~~
- 多线程开发的总结(别人总结的^_^)
- Android面试_别人总结的
- 分享别人ios开发的总结
- 别人的项目总结
- 引用别人的总结
- 别人总结的
- 别人的总结
- 抄录别人的总结
- C++别人的总结
- 别人的总结
- 别人的面试总结
- 黑马程序员_多线程的总结
- JAVA--数据库事务处理(总结别人的)
- Android面试题(别人总结的)
- 转别人的rails总结
- 转别人的rails总结
- 转别人的rails总结
- Hadoop别人的学习总结
- Windows Installer 参数说明
- 排序算法之冒泡排序
- 卸载VS2005 SP1,安装VS2008的一系列问题及其解决
- IIS 错误代码
- string 转 unicode
- 多线程开发的总结(别人总结的^_^)
- C#中获取路径
- 负载均衡交换机知识
- More effective C++ 今日一贴 - 绝不要把多态应用与数组[3]
- HOJ 2728(POJ 1868) Antiarithmetic?
- top命令
- 逆转单向链表
- xampp
- 在重新装好SAP后···