异常日志

异常处理

【强制】不要捕获 Java 类库中定义的继承自 RuntimeException 的运行时异常类,如:IndexOutOfBoundsException / NullPointerException,这类异常由程序员预检查来规避,保证程序健壮性。

正例: if(obj != null) {…}
反例: try { obj.method() } catch(NullPointerException e){…}

【强制】异常不要用来做流程控制,条件控制,因为异常的处理效率比条件分支低。

思考:Scala中用模式匹配处理异常的效率是否会高?

【强制】对大段代码进行 try - catch ,这是不负责任的表现。

catch 时请分清稳定代码和非稳定代码,稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分异常类型,再做对应的异常处理。

【强制】捕获异常是为了处理它,不要捕获了却什么都不处理而抛弃之;

如果不想处理它,请将该异常抛给它的调用者。最外层的业务使用者,必须处理异常,将其转化为用户可以理解的内容。
思考:

【强制】有 try 块放到了事务代码中, catch 异常后,如果需要回滚事务,一定要注意手动回滚事务。

【强制】 finally 块必须对资源对象、流对象进行关闭,有异常也要做 try - catch 。

说明:如果 JDK 7,可以使用 try - with - resources 方式。
思考:finally中的语句,也根据情况要做try-cache

【强制】不能在 finally 块中使用 return , finally 块中的 return 返回后方法结束执行,不会再执行 try 块中的 return 语句。

思考:finally中的return有效,但是就算有效,也没有意义,因为无论如何,都会返回同样的值

【强制】捕获异常与抛异常,必须是完全匹配,或者捕获异常是抛异常的父类。

说明:如果预期对方抛的是绣球,实际接到的是铅球,就会产生意外情况。

推荐】方法的返回值可以为 null ,不强制返回空集合,或者空对象等,必须添加注释充分说明什么情况下会返回 null 值。调用方需要进行 null 判断防止 NPE 问题。

说明:本规约明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象,对调用者来说,也并非高枕无忧,必须考虑到远程调用失败,运行时异常等场景返回 null 的情况
思考:如果返回的是null,需要添加说明。

【推荐】防止 NPE ,是程序员的基本修养,注意 NPE 产生的场景:

1 ) 返回类型为包装数据类型,有可能是 null ,返回 int 值时注意判空。
反例: public int f() { return Integer 对象}; 如果为 null ,自动解箱抛 NPE 。
2 ) 数据库的查询结果可能为 null 。
3 ) 集合里的元素即使 isNotEmpty ,取出的数据元素也可能为 null 。
4 ) 远程调用返回对象,一律要求进行 NPE 判断。
5 ) 对于 Session 中获取的数据,建议 NPE 检查,避免空指针。
6 ) 级联调用 obj . getA() . getB() . getC(); 一连串调用,易产生 NPE 。

【推荐】在代码中使用“抛异常”还是“返回错误码”,对于公司外的 http / api 开放接口必须使用“错误码” ; 而应用内部推荐异常抛出 ; 跨应用间 RPC 调用优先考虑使用 Result 方式,封装 isSuccess 、“错误码”、“错误简短信息”。

说明:关于 RPC 方法返回方式使用 Result 方式的理由:
1 ) 使用抛异常返回方式,调用方如果没有捕获到就会产生运行时错误。
2 ) 如果不加栈信息,只是 new 自定义异常,加入自己的理解的 error message ,对于调用
端解决问题的帮助不会太多。如果加了栈信息,在频繁调用出错的情况下,数据序列化和传输
的性能损耗也是问题。

【推荐】定义时区分 unchecked / checked 异常,避免直接使用 RuntimeException 抛出,更不允许抛出 Exception 或者 Throwable ,应使用有业务含义的自定义异常。

【参考】避免出现重复的代码 (Don ’ t Repeat Yourself) ,即 DRY 原则。

说明:随意复制和粘贴代码,必然会导致代码的重复,在以后需要修改时,需要修改所有的副
本,容易遗漏。必要时抽取共性方法,或者抽象公共类,甚至是共用模块。
正例:一个类中有多个 public 方法,都需要进行数行相同的参数校验操作,这个时候请抽取:
private boolean checkParam(DTO dto){…}

日志规约

【强制】应用中不可直接使用日志系统 (Log 4 j 、 Logback) 中的 API ,而应依赖使用日志框架SLF4J中的 API ,使用门面模式的日志框架,有利于维护和各个类的日志处理方式统一。

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Abc.class);
思考:回头要注意,使用门面模式的日志框架

【强制】日志文件推荐至少保存 15 天,因为有些异常具备以“周”为频次发生的特点。

【强制】应用中的扩展日志 ( 如打点、临时监控、访问日志等 ) 命名方式:

appName_logTypelogName.log 。
logType :日志类型,推荐分类有 stats / desc / monitor / visit 等 ;
logName :日志描述。这种命名的好处:通过文件名就可知道日志文件属于什么应用,什么类型,什么目的,也有利于归类查找。
正例: mppserver 应用中单独监控时区转换异常,如:
mppserver
monitor _ timeZoneConvert . log
说明:推荐对日志进行分类,错误日志和业务日志尽量分开存放,便于开发人员查看,也便于
通过日志对系统进行及时监控。
思考:原来我想到的别人已经想到了,一定践行;

【强制】对 trace / debug / info 级别的日志输出,必须使用条件输出形式或者使用占位符的方式。

说明: logger . debug( “ Processing trade with id : “ + id + “ symbol : “ + symbol);
如果日志级别是 warn ,上述日志不会打印,但是会执行字符串拼接操作,如果 symbol 是对象,
会执行 toString() 方法,浪费了系统资源,执行了上述操作,最终日志却没有打印。
正例: ( 条件 )

1
2
3
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " symbol: " + symbol);
}

正例: ( 占位符 )

1
logger.debug("Processing trade with id: {} symbol : {} ", id, symbol);

思考:这一点非常重要,学到了,既然这样,就直接统一使用占位符的方式吧;

【强制】避免重复打印日志,浪费磁盘空间,务必在 log4j.xml 中设置 additivity = false。

正例:

【强制】异常信息应该包括两类信息:案发现场信息和异常堆栈信息。如果不处理,那么往上抛。

正例: logger.error(各类参数或者对象 toString + “_” + e.getMessage(), e);
思考:一定要注意保留这两类信息:e.getMessage();

【推荐】可以使用 warn 日志级别来记录用户输入参数错误的情况,避免用户投诉时,无所适从。

注意日志输出的级别, error 级别只记录系统逻辑出错、异常等重要的错误信息。如非必要,请不要在此场景打出 error 级别。

【推荐】谨慎地记录日志。生产环境禁止输出 debug 日志 ; 有选择地输出 info 日志 ; 如果使用 warn 来记录刚上线时的业务行为信息,一定要注意日志输出量的问题,避免把服务器磁盘撑爆,并记得及时删除这些观察日志。

说明:大量地输出无效日志,不利于系统性能提升,也不利于快速定位错误点。记录日志时请
思考:这些日志真的有人看吗?看到这条日志你能做什么?能不能给问题排查带来好处?

Mysql规约

建表规约

【强制】表达是与否概念的字段,必须使用 is _ xxx 的方式命名,数据类型是 unsigned tinyint(1表示是,0表示否),此规则同样适用于 odps 建表。

说明:任何字段如果为非负数,必须是 unsigned 。

【强制】表名、字段名必须使用小写字母或数字 ; 禁止出现数字开头,禁止两个下划线中间只出现数字。数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑。

正例: getter admin , task config , level 3_ name
反例: GetterAdmin , taskConfig , level 3 name
思考:因为以前遇到坑,不同数据库大小写规则不一样,所以都用小写

【强制】表名不使用复数名词。

说明:表名应该仅仅表示表里面的实体内容,不应该表示实体数量,对应于 DO 类名也是单数形式,符合表达习惯。

【强制】唯一索引名为 uk 字段名 ; 普通索引名则为 idx 字段名。

说明: uk 即 unique key;idx 即 index 的简称。

【强制】小数类型为 decimal ,禁止使用 float 和 double 。

说明: float 和 double 在存储的时候,存在精度损失的问题,很可能在值的比较时,得到不
正确的结果。
如果存储的数据范围超过 decimal 的范围,建议将数据拆成整数和小数分开存储。

【强制】如果存储的字符串长度几乎相等,使用 char 定长字符串类型。

【强制】 varchar 是可变长字符串,不预先分配存储空间,长度不要超过 5000,如果存储长度大于此值,定义字段类型为 text ,独立出来一张表,用主键来对应,避免影响其它字段索引效率。

【强制】表必备三字段: id , gmt_create,gmt_modified。

说明:其中 id 必为主键,类型为 unsigned bigint 、单表时自增、步长为 1。 gmt_create,gmt_modified 的类型均为 date_time 类型。

【推荐】表的命名最好是加上“业务名称_表的作用”。

正例: tiger_task/tiger_reader/mpp_config

【推荐】库名与应用名称尽量一致。

【推荐】字段允许适当冗余,以提高性能,但是必须考虑数据同步的情况。冗余字段应遵循:

1 ) 不是频繁修改的字段。
2 ) 不是 varchar 超长字段,更不能是 text 字段。
正例:商品类目名称使用频率高,字段长度短,名称基本一成不变,可在相关联的表中冗余存
储类目名称,避免关联查询。

【推荐】单表行数超过 500 万行或者单表容量超过 2 GB ,才推荐进行分库分表。

说明:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。

索引规约

这一块,现在理解不深,需要使用的时候再理解

【强制】业务上具有唯一特性的字段,即使是组合字段,也必须建成唯一索引。

说明:不要以为唯一索引影响了 insert 速度,这个速度损耗可以忽略,但提高查找速度是明
显的 ;

【强制】 超过三个表禁止 join 。需要 join 的字段,数据类型保持绝对一致 ; 多表关联查询时,保证被关联的字段需要有索引。

说明:即使双表 join 也要注意表索引、 SQL 性能。

【强制】在 varchar 字段上建立索引时,必须指定索引长度,没必要对全字段建立索引,根据实际文本区分度决定索引长度。

说明:索引的长度与区分度是一对矛盾体,一般对字符串类型数据,长度为 20 的索引,区分度会高达 90%以上,可以使用 count(distinct left( 列名, 索引长度 )) / count( * ) 的区分度来确定。

【强制】页面搜索严禁左模糊或者全模糊,如果需要请走搜索引擎来解决。

说明:索引文件具有 B - Tree 的最左前缀匹配特性,如果左边的值未确定,那么无法使用此索引。

【参考】创建索引时避免有如下极端误解:

1 ) 误认为一个查询就需要建一个索引。
2 ) 误认为索引会消耗空间、严重拖慢更新和新增速度。
3 ) 误认为唯一索引一律需要在应用层通过“先查后插”方式解决。

SQL规约

【强制】不要使用count(列名)或count(常量)来替代count(),count()就是 SQL92定义的标准统计行数的语法,跟数据库无关,跟 NULL 和非 NULL 无关。

说明: count(*)会统计值为NULL的行,而count(列名)不会统计此列为NULL值的行。

【强制】使用 ISNULL() 来判断是否为 NULL 值。注意: NULL 与任何值的直接比较都为 NULL。

说明:
1 ) NULL<>NULL 的返回结果是 NULL ,而不是 false 。
2 ) NULL=NULL 的返回结果是 NULL ,而不是 true 。
3 ) NULL<>1 的返回结果是 NULL ,而不是 true 。

【强制】不得使用外键与级联,一切外键概念必须在应用层解决。

【强制】禁止使用存储过程,存储过程难以调试和扩展,更没有移植性。

【强制】数据订正时,删除和修改记录时,要先 select ,避免出现误删除,确认无误才能执行更新语句。

【推荐】 in 操作能避免则避免,若实在避免不了,需要仔细评估 in 后边的集合元素数量,控制在 1000 个之内。

【参考】如果有全球化需要,所有的字符存储与表示,均以 utf -8 编码,那么字符计数方法

说明:
SELECT LENGTH( “轻松工作” ); 返回为 12
SELECT CHARACTER_LENGTH( “轻松工作” ); 返回为 4
如果要使用表情,那么使用 utfmb 4 来进行存储,注意它与 utf -8 编码的区别。

【参考】TRUNCATE TABLE 比 DELETE 速度快,且使用的系统和事务日志资源少,但TRUNCATE无事务且不触发 trigger ,有可能造成事故,故不建议在开发代码中使用此语句。

说明: TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。

ORM规约

【强制】在表查询中,一律不要使用 * 作为查询的字段列表,需要哪些字段必须明确写明。

说明:1 ) 增加查询分析器解析成本。2 ) 增减字段容易与 resultMap 配置不一致。
思考:这一点我做得不好,一定需要注意;

【强制】 POJO 类的 boolean 属性不能加 is ,而数据库字段必须加 is _,要求在 resultMap中进行字段与属性之间的映射。

说明:参见定义 POJO 类以及数据库字段定义规定,在 sql . xml 增加映射,是必须的。

【强制】不要用 resultClass 当返回参数,即使所有类属性名与数据库字段一一对应,也需要定义 ; 反过来,每一个表也必然有一个与之对应。

说明:配置映射关系,使字段与 DO 类解耦,方便维护。

【强制】 xml 配置中参数注意使用:#{},# param # 不要使用${} 此种方式容易出现SQL注入。

【强制】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。

思考:为啥?

【强制】更新数据表记录时,必须同时更新记录对应的 gmt _ modified 字段值为当前时间。

【推荐】不要写一个大而全的数据更新接口,传入为 POJO 类,不管是不是自己的目标更新字段,都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。

执行 SQL时,尽量不要更新无改动的字段,一是易出错 ; 二是效率低 ; 三是 binlog 增加存储。

【参考】@ Transactional 事务不要滥用。事务会影响数据库的 QPS ,另外使用事务的地方需要考虑各方面的回滚方案,包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。

【参考】< isEqual >中的 compareValue 是与属性值对比的常量,一般是数字,表示相等时带上此条件 ; < isNotEmpty >表示不为空且不为 null 时执行 ; < isNotNull >表示不为 null 值时执行。

工程规约

【强制】定义 GAV 遵从以下规则:

1 ) GroupID 格式:com.{公司/BU}.业务线.[子业务线],最多4级。
说明:{公司/BU}例如:alibaba/taobao/tmall/aliexpress等BU一级;子业务线可选。
正例:com.taobao.jstorm或com.alibaba.dubbo.register
2)ArtifactID格式:产品线名-模块名。语义不重复不遗漏,先到仓库中心去查证一下。
正例:dubbo-client/fastjson-api/jstorm-tool
3)Version:详细规定参考下方。

思考:com.ctcc.bigdata openapi-storage

【强制】二方库版本号命名方式:主版本号.次版本号.修订号

1 ) 主版本号 :当做了不兼容的 API 修改,或者增加了能改变产品方向的新功能。
2 ) 次版本号 :当做了向下兼容的功能性新增 ( 新增类、接口等 ) 。
3 ) 修订号 :修复 bug ,没有修改方法签名的功能加强,保持 API 兼容性。
说明:起始版本号必须为: 1.0.0 ,而不是 0.0.1

【强制】线上应用不要依赖 SNAPSHOT 版本 ( 安全包除外 );

正式发布的类库必须使用 RELEASE版本号升级+1 的方式,且版本号不允许覆盖升级,必须去中央仓库进行查证。
说明:不依赖 SNAPSHOT 版本是保证应用发布的幂等性。另外,也可以加快编译时的打包构建。

【强制】二方库里可以定义枚举类型,参数可以使用枚举类型,但是接口返回值不允许使用枚举类型或者包含枚举类型的 POJO 对象。

【强制】依赖于一个二方库群时,必须定义一个统一版本变量,避免版本号不一致。

说明:依赖 springframework - core ,- context ,- beans ,它们都是同一个版本,可以定义一个变量来保存版本:${ spring . version },定义依赖的时候,引用该版本。

【强制】禁止在子项目的 pom 依赖中出现相同的 GroupId ,相同的 ArtifactId ,但是不同的Version 。

说明:在本地调试时会使用各子项目指定的版本号,但是合并成一个 war ,只能有一个版本号出现在最后的 lib 目录中。曾经出现过线下调试是正确的,发布到线上出故障的先例。

服务器规约

【推荐】高并发服务器建议调小 TCP 协议的 time _ wait 超时时间。

说明:操作系统默认 240 秒后,才会关闭处于 time wait 状态的连接,在高并发访问下,服务器端会因为处于 time wait 的连接数太多,可能无法建立新的连接,所以需要在服务器上调小此等待值。

【推荐】调大服务器所支持的最大文件句柄数 (File Descriptor ,简写为 fd) 。

说明:主流操作系统的设计是将 TCP / UDP 连接采用与文件一样的方式去管理,即一个连接对应于一个 fd 。主流的 linux 服务器默认所支持最大 fd 数量为 1024,当并发连接数很大时很容易因为 fd 不足而出现“ open too many files ”错误,导致新的连接无法建立。 建议将 linux服务器所支持的最大句柄数调高数倍 ( 与服务器的内存数量相关 ) 。
思考:kafka ,flume等中间件也要这么配

【推荐】给 JVM 设置- XX :+ HeapDumpOnOutOfMemoryError 参数,让 JVM 碰到 OOM 场景时输出dump 信息。

说明: OOM 的发生是有概率的,甚至有规律地相隔数月才出现一例,出现时的现场信息对查错非常有价值。

【参考】服务器内部重定向使用 forward; 外部重定向地址使用 URL 拼装工具类来生成,否则会带来 URL 维护不一致的问题和潜在的安全风险。

安全规约

【强制】隶属于用户个人的页面或者功能必须进行权限控制校验。

说明:防止没有做水平权限校验就可随意访问、操作别人的数据,比如查看、修改别人的订单。

【强制】用户敏感数据禁止直接展示,必须对展示数据脱敏。

说明:查看个人手机号码会显示成:158**9119,隐藏中间 4 位,防止隐私泄露。
思考:在openAPI项目中一定要注意;

【强制】用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定,防止 SQL 注入,

禁止字符串拼接 SQL 访问数据库。

【强制】用户请求传入的任何参数必须做有效性验证。

说明:忽略参数校验可能导致:
 page size 过大导致内存溢出
 恶意 order by 导致数据库慢查询
 任意重定向
 SQL 注入
 反序列化注入
 正则输入源串拒绝服务 ReDoS
说明:Java 代码用正则来验证客户端的输入,有些正则写法验证普通用户输入没有问题,但是如果攻击人员使用的是特殊构造的字符串来验证,有可能导致死循环的效果。

【强制】禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。

【强制】在使用平台资源,譬如短信、邮件、电话、下单、支付,必须实现正确的防重放限制,如数量限制、疲劳度控制、验证码校验,避免被滥刷、资损。

说明:如注册时发送验证码到手机,如果没有限制次数和频率,那么可以利用此功能骚扰到其
它用户,并造成短信平台资源浪费。

思考

这两天断断续续看完了全部,看得时候觉得受益匪浅,但是这种东西要消化成自己的知识,一定要践行,等编码到具体部分的时候再复习,写出优秀的代码。