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的发生是有概率的，甚至有规律地相隔数月才出现一例，出现时的现场信息对查错非常有价值。