java experience

• webservice接口抛出异常必定要用checked exception，最好不要用exception用resultdto
• 线程池不容许使用Executors去建立，而是经过ThreadPoolExecutor的方式，规避资源耗尽的风险。
• 高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。
• 并发修改同一记录时，避免更新丢失，要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version做为更新依据。说明：若是每次访问冲突几率小于20%，推荐使用乐观锁，不然使用悲观锁。乐观锁的重试次数不得小于3次。
• 多线程场景下使用hashmap致使cpu高，可能不是本身写的是引用第三方框架致使的，须要经过查看jstack日志
• 不要强依赖缓存，须要缩短缓存超时时间，取不出来直接走db
• all inputs is evil,养成输入数据过滤、输出数据转义的开发习惯
• 调用远程操做必须有超时设置。HSF默认自动超时是3秒，相似于Httpclient的超时设置须要本身明确去设置Timeout
• 分布式事务处理最大的问题是分布式死锁，基于等待图的检测不可伸缩性能也不可接受，超时则不及时。规避分布式死锁的好方法是统一顺序，在事务涉及的节点已知时可完美处理，在涉及的节点须要动态扩时要经过时间戳来判断是否违反顺序，违反则restart
• 高并发服务器建议调小TCP协议的time_wait超时时间。
• 说明：操做系统默认240秒后，才会关闭处于time_wait状态的链接，在高并发访问下，服务器端会由于处于time_wait的链接数太多，可能没法创建新的链接，因此须要在服务器上调小此等待值。
• 正例：在linux服务器上请经过变动/etc/sysctl.conf文件去修改该缺省值（秒）：net.ipv4.tcp_fin_timeout = 30
• 调大服务器所支持的最大文件句柄数（File Descriptor，简写为fd）。
• 说明：主流操做系统的设计是将TCP/UDP链接采用与文件同样的方式去管理，即一个链接对应于一个fd。集团使用主流的linux服务器默认所支持最大fd数量为1024，当并发链接数很大时很容易由于fd不足而出现“open too many files”错误，致使新的链接没法创建。 建议将linux服务器所支持的最大句柄数调高数倍（与服务器的内存数量相关）。
• 给JVM设置-XX:+HeapDumpOnOutOfMemoryError参数，让JVM碰到OOM场景时输出dump信息。
• 说明：OOM的发生是有几率的，甚至有规律地相隔数月才出现一例，出现时的现场信息对查错很是有价值。