一些经验总结

应用层：

 

1）  尽量减少在方法上面加上synchronized关键字，可以在方法内部加，前者是类级别的锁，后者是对象级别的，如果lock可以满足，多使用lock接口，并发情况下，lock性能会更好

 

2）  缓存也可以在线程内做，通过ThreadLocal来实现，这样我们服务端缓存就可以变成

线程级别-》JVM级别-》本地文件-》memcached等分布式缓存-》DB

 

3）  减少网络通信频率，如对缓存和DB的操作，可以批量做的尽量批量实现，例如对于一些非重要数据，可以异步更新，JVM内部起一个守护线程做轮询，根据自定义规则批量更新到缓存和DB中

 

4）  Memcached中存放集合数据，可以将每天数据单独存入到缓存中，新建一个单独的key管理这些集合的key列表，这样虽然取了两次，但是可以大大降低通信的数据量。

 

5） 日志的规范，之前的公司所做的项目是所有模块都集成在一个工程中，因此出了问题查看log的时候不太好定位，后来约定每个模块的log都加上自己的规范，写一个日志分析程序定位哪些模块出的错误数量和错误详细信息等等

 

6）异常信息的规范，每个模块需要加上自定义异常，将JVM运行时异常与自定义异常分开，自定义异常也可以细分，有些业务比如查DB不应该为空但结果也是空，我们可以划分在自定义异常内，等等。另外针对客户端程序如果也有自己的运行进程（比如AS3、C++等等）服务端可以制定一套异常码配置，客户端与服务端异常码配置保持一致，服务端出错只需要返回给客户端异常码，客户端即可找到相对于异常信息，这样可以降低通信数据大小

 

7）应用服务器可以选择NIO，tomcat默认为BIO，能够响应线程大概800，改成NIO之后可以翻倍，JETTY现在还不太清楚

 

8）代码中不可以出现主动回收内存，尽量降低通过JAVA调用shell脚本代码执行频率

 

9）开发过程中可以考虑用jvisualvm、jconsole观察程序运行状况，有的时候甚至可以调试BUG

 

10）如果是后台任务，可以通过多线程任务提供效率

 

11）如何防止、降低OOM出现的频率

  

    11.1） 避免大对象、更要避免频繁回收的大对象

    11.2） 方法不要太长

    11.3） 减少循环的嵌套

    11.4） 避免反射引起的PerGemSpace oom

    11.5） 减少使用unsafe.allocateMemory()，有可能导致堆外内存溢出（之前使用MC客户端出现过这样的BUG）

    ....

 

12）减少项目的三方依赖，降低系统的复杂度

 

13）服务器如果是多核垃圾回收最好使用并发回收、堆内存最大值和最小值设置相同

 

 

数据层：

 

   1）非重要数据需要及时响应可以考虑附加mongodb，优点是速度快，支持集群、主从等。缺点是语法不丰富，data文件大，相关更专业人员不多，统计需求很不方便

 

   2）需要及时响应，数据结构较丰富的可以考虑redis，微博一直在使用，之前部门有一个模块的排行榜功能在用redis

 

   3）mysql需要做主从，从库满足读需求

 

   4）尽量避免联表查询

 

   5）尽量避免like %% 语法

 

   6）复杂的任务可以在DB端用存储过程实现

 

   7）http://blog.nosqlfan.com/

 

 

  

 

其它：

 

   1）需求大于一切，可以帮助产品、运营捋清楚我们的需求，我们产品的定位，需求确定之后再去做，免得周而复返

  

   2）沟通很重要，能见面沟通就别打电话，能打电话就别发邮件...

 

   3）文档能够帮自己梳理设计思路，能够帮助后人便于上手

      注释同上

  

   4）......