阿里java开发规范学习笔记 （七）其他/工程结构

java开发规范学习记录到本章结束。

(九) 其它
1. 【强制】在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度。 
说明：不要在方法体内定义：Pattern pattern = Pattern.compile(规则);
【尝试从配置中传入正则表达式，那么可以采用读进来 在初始化完成正则表达式的编译 不在每次调用时去匹配 提高匹配速度】
例子： 
在spring 初始化时,不仅基础类型可以使用@value注解 方法也可以(考虑做)
@value
private initXXXXPattern(String xxxString) {
  if (check(xxxString)) {
  this.xxxPattern = Pattern.compile(xxxString);
  }
  LOG.warn("wrong")
}


5. 【强制】获取当前毫秒数System.currentTimeMillis(); 而不是new Date().getTime(); 说明：如果想获取更加精确的纳秒级时间值，使用System.nanoTime()的方式。
在JDK8中，针对统计时间等场景，推荐使用Instant类。
【需要加大对JDK8 中 时间类的了解,之前浅显的看过,针对时区,线程安全等的优化,但是如何灵活使用,还需要多练习】


8. 【推荐】及时清理不再使用的代码段或配置信息。
说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。
正例：对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)来说明注释掉代码的理由。
【配置文件非常的冗长。。老的配置信息，例如编写时的过多的debug日志、断点代码、挡板返回标识等】


3. 【强制】对大段代码进行try-catch，这是不负责任的表现。catch时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。
对于非稳定代码的catch尽可能进行区分异常类型，再做对应的异常处理。
【刚接项目活时，新手上路，大量的try catch 表现出对稳定性分析的不够，实际上只需要对真正有异常的地方捕获，对于每个地方都try catch 那说明很多地方没想清楚或惧怕不自信】


6. 【强制】finally块必须对资源对象、流对象进行关闭，有异常也要做try-catch。 说明：如果JDK7及以上，可以使用try-with-resources方式。
【之前回收资源还在 finally里面做，现在有resources，应该采用其进行资源回收，回收时的错，例如资源不存在根本没打开的异常捕获了可以打一条info帮助自己解析
（关闭流结果是打开时失败的异常，所以在finally中close 一定会报错）】


13. 【参考】避免出现重复的代码（Don’t Repeat Yourself），即DRY原则。 说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化。 正例：一个类中有多个public方法，都需要进行数行相同的参数校验操作，这个时候请抽取：
private boolean checkParam(DTO dto) {...}
【能提的尽量提到公共包/各种方法中,复制粘贴带来的维护惨痛经历,前人告诉的太多了...自己也体会到了部分,虽然不惨痛,但是够痛苦】


7. 【推荐】谨慎地记录日志。生产环境禁止输出debug日志；有选择地输出info日志；如果使用warn来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。 
说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。
【记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？】
【使用IDE时，拍错时，需要输出的信息 能够帮助排查的才打，多余的没用啊啊啊啊啊，或者没有日志怎么查】


(二) 索引规约
这一部分，作为知识点学习，在设计数据库时，没有过多参加。无法亲身做优化时，这些规则带来的优势。


六、工程结构
(一) 应用分层
3. 【参考】分层领域模型规约：
 DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
 DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
 BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。
 AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
 VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
 Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。、
【先用着】


9. 【推荐】二方库不要有配置项，最低限度不要再增加配置项。
10. 【参考】为避免应用二方库的依赖冲突问题，二方库发布者应当遵循以下原则：
 1）精简可控原则。移除一切不必要的API和依赖，只包含 Service API、必要的领域模型对象、Utils类、常量、枚举等。如果依赖其它二方库，尽量是provided引入，
 让二方库使用者去依赖具体版本号；无log具体实现，只依赖日志框架。 
 2）稳定可追溯原则。每个版本的变化应该被记录，二方库由谁维护，源码在哪里，都需要能方便查到。除非用户主动升级版本，否则公共二方库的行为不应该发生变化。
【项目的二方库 基础包 有日志框架，并且log的具体实现是放在配置项之中，维护简单了，但是改动起来很复杂】
例：
基类工程base包中定义了日志，及其日志配置项。
依赖的4个工程都不需要添加日志修改项，这样感觉是可行的。
但是如果base包中有个配置项，子工程有一个工程的配置要做此配置项做修改，修改不了。。。必须打开base的jar包重写配置项，增加了维护修改难度。


1. 【推荐】高并发服务器建议调小TCP协议的time_wait超时时间。 
说明：操作系统默认240秒后，才会关闭处于time_wait状态的连接，
在高并发访问下，服务器端会因为处于time_wait的连接数太多，可能无法建立新的连接，
所以需要在服务器上调小此等待值。 正例：在linux服务器上请通过变更/etc/sysctl.conf文件去修改该缺省值（秒）： net.ipv4.tcp_fin_timeout = 30
【项目没设置该时间，dubbo貌似有自动关闭连接的能力，所以暂未考虑设置该值】


2. 【推荐】调大服务器所支持的最大文件句柄数（File Descriptor，简写为fd）。 
说明：主流操作系统的设计是将TCP/UDP连接采用与文件一样的方式去管理，即一个连接对应于一个fd。
主流的linux服务器默认所支持最大fd数量为1024，当并发连接数很大时很容易因为fd不足而出现“open too many files”错误，
导致新的连接无法建立。 建议将linux服务器所支持的最大句柄数调高数倍（与服务器的内存数量相关）。
【项目没调该参数，但是遇到了dubbo建立了1024+个线程后,该问题暴露】


3. 【推荐】给JVM设置-XX:+HeapDumpOnOutOfMemoryError参数，让JVM碰到OOM场景时输出dump信息。
4. 【推荐】在线上生产环境，JVM的Xms和Xmx设置一样大小的内存容量，避免在GC 后调整堆大小带来的压力。
说明：OOM的发生是有概率的，甚至有规律地相隔数月才出现一例，出现时的现场信息对查错非常有价值。
【崩溃时，输出堆栈信息，才能看到问题，不然一头雾水。刚开始服务都只设置了1G内存，频繁拼接字符串和new 对象的service层的MGC 非常 非常的频繁
，而且现在项目给的内存非常多 都是8G 16G上面部一个服务，那么不把JVM的内存大小改成4G以上 对得起这么大的内存吗】


上面是针对java手册中，提取的常常容易出错的部分。


望自己以后能够把其中高并发/集合部分能够有更深一层的理解和感悟。
还有JDK 8的新时间类型,localtime 和 instant 类的练习。