1. 1、资源是有限的 
  2. 无论是何种方式获得数据&＃xff0c;最好还是采用分页。如果万一一个bug的出现&＃xff0c;导致成上100万的数据查询出来&＃xff0c;不光是一个java进程down掉的问题&＃xff0c;可能整片都会出问题。 
  3. 事情的发生往往都是滚雪球的效应。 
  4. 2、依赖是未知的 
  5. 对于慢速系统或者不可靠系统、未知系统&＃xff0c;做好做成异步。 
  6. 对于优先级很高的调用&＃xff0c;采用异步通知或者等待的模式。对于优先级很低的调用&＃xff0c;直接采用异步&＃xff0c;无须等待&＃xff0c;通过监控和告警监控。 
  7. CPU的速率很快&＃xff0c;磁盘的转速很慢&＃xff0c;一个依赖于文件系统的系统永远的速度只能达到磁盘响应的速度。 
  8. 3、线程安全与性能 
  9. 对于查询很多&＃xff0c;写入很少的&＃xff0c;还是直接采用HashMap&＃xff0c;写入的时候采用lock锁 
  10. 对于写多&＃xff0c;读少的&＃xff0c;采用ConcurrentHashMap 
  11. 如果仅仅是一个线程操作这个数据&＃xff0c;根本没有争用的情况&＃xff0c;直接使用HashMap 
  12. ThreadLocal这样的对象&＃xff0c;尽量不要开放给普通开发人员使用&＃xff1b;这个对象的在线程的执行最前面&＃xff0c;加上一个设置为空的操作&＃xff0c;尽量减少ThreadLocal重复利用的问题。 
  13. 4、资源释放 
  14. 原则是那里获得那里释放。 
  15. 无论已经做了连接池的连接还是IO对象&＃xff0c;全部采用那里获得那里释放的原则。 
  16. 同时&＃xff0c;也要考虑释放多个资源&＃xff0c;如果第一个出现异常&＃xff0c;后面中断的问题。 
  17. 5、创建与复用 
  18. 对于采用分代并行垃圾回收算法的jdk&＃xff0c;小对象的频繁创建和消耗对于性能的损耗几乎看不见。 
  19. 对于没有采用分代垃圾算法的jdk&＃xff0c;特别是IBM的jdk&＃xff0c;小心造成垃圾碎片&＃xff0c;引起OOM。 
  20. 对于java的nio的网络通讯层面&＃xff0c;ByteBuffer是一个能极大的减少内存创建的类&＃xff0c;可以做到zero copy对象到网络层&＃xff0c;极大的提高通讯的性能。 
  21. 6、字符串处理&＃xff0c;日志级别的选择 
  22. 对于JDK1.5或者以上版本&＃xff0c;使用&＃43;连接多个字符串&＃xff0c;jdk编译器会自动采用StringBuilder进行优化&＃xff0c;可以反编译看。很多文章或者书上写到&＃xff0c;必须采用StringBuffer的方式&＃xff0c; 
  23. 其实可以不用考虑&＃xff0c;采用&＃43;的方式效率反而比采用StringBuffer高&＃xff0c;StringBuffer的每个方法都采用了锁。 
  24. 日志级别在上线初期&＃xff0c;可能会是info&＃xff0c;甚至debug。在稳定一段时间后&＃xff0c;一定要恢复到采用error级别。 
  25. 我们全部采用日志输出到cronolog的方式。 
  26. 很多地方写日志的方法很不正确。 
  27. log.debug("测试日志输出"&＃43;System.getProperties()); 
  28. 最好改成这样 
  29. if(log.isDebugEnable()){ 
  30. log.debug("测试日志输出"&＃43;System.getProperties()); 
  31. } 
  32. 按照java的习惯&＃xff0c;即使日志不输出&＃xff0c;但是字符串还是要拼接的&＃xff0c;也对性能有损耗。 
  33. 7、原子操作与并发控制 
  34. 对于集群的并发控制&＃xff0c;要么采用数据库&＃xff0c;要么采用memcached。当然memcached性价比远远优于数据库。 
  35. 对于一个进程内部的并发&＃xff0c;jdk1.5提供了很多很好使用的类。 
  36. 比如&＃xff1a;AtomicLong&＃xff0c;Lock等等 
  37. 8、灵活性和性能和可维护性的折中 
  38. spring是个好东西&＃xff0c;看到使用几十个甚至上百个spring的配置文件&＃xff0c;甚至在不同的目录或者jar里面&＃xff0c;以后的维护是件及其麻烦的事情。 
  39. 为什么不能将这样配置统一到数据库中&＃xff0c;进行统一的管理和配置。 
  40. 9、要有分布式和并发的观念&＃xff0c;但是不要本末倒置 
  41. 这句话没错&＃xff0c;但是要求所有的开发人员都要知道这么多细枝末节的东西&＃xff0c;甚至要关系主机、数据库和网络环境岂不是增大了出现问题的可能性。 
  42. 开发人员需要投入绝大多数精力在业务上&＃xff0c;而不是耗在无谓的系统怎么样部署、怎么样分布式上面。 
  43. 框架就是来支持这个的&＃xff0c;给出一套开发规范&＃xff0c;在框架上做出不符合这样规范的写法的错误捕获和提示&＃xff0c;都是可以实施的。 
  44. 10、便利性的函数与性能的冲突 
  45. SimpleDateFormat就是一个典型的例子。jdk的代码是写的不错&＃xff0c;但是也有写的很烂的代码。 
  46. 对于时间和日期的处理&＃xff0c;我们一直都采用joda-time&＃xff0c;性能好的很多。 
  47. 11、多级缓存和异步缓解异构系统的瓶颈 
  48. 还是上面的话&＃xff0c;凡是不能控制的系统&＃xff0c;就当成不信任的系统&＃xff0c;尽量的异步&＃xff0c;尽量的资源限制。 
  49. 12、运行期白盒化&＃xff0c;模块可重置 
  50. 模块可重置&＃xff0c;这个是个高科技&＃xff0c;不知道采用什么办法做到的。 
  51. 如果是采用传统的ejb&＃xff0c;支持热下线和热上线&＃xff0c;做做demo可以&＃xff0c;生产系统放到一边去。 
  52. 如果采用OSGi&＃xff0c;本人没接触过。 
  53. 去年本人维护一个非常高可用的系统也对模块可重置想过很多&＃xff0c;一直没有什么真正可在生产环境实施的方案。 
  54. 13、懒惰有时候是件好事 
  55. 这句话非常的好&＃xff0c;加上一个限定条件就更好了&＃xff0c;在有利工作的情况下懒惰。 
  56. 比如说&＃xff1a;重复性的工作&＃xff0c;懒得的人就会想出很多办法提高效率。 
  57.  
  58. 本人(msn:cauherk&＃64;hotmail.com)去年参与了5000万用户的系统的架构、设计和开发&＃xff0c;采用了纯J2EE&＃xff0c;集群、分布式、分库&＃xff08;横向和纵向&＃xff09;、分表技术实施。 
  59. 平均每天的业务量达到了400万笔交易。非常想和同道人一起讨论架构和技术问题。