阿里java开发手册-泰山版--阅读摘记（编程规约2）

日期时间

集合处理

hashcode方法实际上是在根据对象的地址和字段的属性值来获得一个映射值----散列值，equals也是在比较这个散列值

优秀的代码

stream操作转换为map时需要注意

这个我还没碰着过，基本是都是基于value定制化的key，很少有key有但value没有的情况，但确实存在

多线程的情况吗，目前没有想到这种场景

这个我用过，但实际上使用的时候都是在做一个拼接过程，针对的也是string，基本不会出问题

Optional.of("EodRate"+ "#"+
              "Eod rate not found，currencyPair：" + StringUtils.join(newError.toArray(), ","));

并发处理

ThreadPoolExecutor/ThreadPoolTaskExecutor 后者的实现依赖于前者，额外增加了拒绝策略的功能

那一个超级庞大的锁，咋处理


简单来说：如果表会被频繁使用到去显示数据，就采用乐观锁，反之是在表读取之后基本上就会修改。

悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。

乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

悲观锁–for update
select 1 from syn_table where name=#{name} and type=#{type} for update
两个要求：
数据库的引擎为 innoDB
操作位于事务块中（BEGIN/COMMIT）
四种情况：
若明确指明主键，且结果集有数据，行锁；
若明确指明主键，结果集无数据，则无锁；
若无主键，且非主键字段无索引，则表锁；
若使用主键但主键不明确，则使用表锁；

countdown和await，countdown必须放在finally里面，await不能再线程运行的内部，要在外部做统一等待？是的！

没用过，但我个人感觉，就放在加锁的代码块里，就可以了，没必要整这个

死链：还得是高并发，哪个傻子会在高并发下用这个？

控制语句

自动拆箱导致的问题，本来是integral，屁事没有，拆箱就出错了。

等值条件做为结束条件导致的“击穿”，高并发下会直接到达负值，而不会停留在等值。

if else控制语句
卫语句：拆分出多条if，取出else，个人的理解是，如果逻辑确实太长了，这么写还是可以的，但不多的话，还是else会更有逻辑结构一点。
策略模式实际上就是多态，原来这玩意还能有一个专业的名称。
在看完状态模式之后，我觉得上面的好像并没有想的那么简单。

我在使用的时候，基本上不会考虑吧boolean抽出来，太费脑细胞了，而且在stream操作中，这种操作无线多。


每一个接口都要做参数限制，如果参数会反映在数据库连接上，就需要对相关参数，比如页数，size进行控制。
参数校验是一项很吃力的工作，如果方法在实际的应用中并不多，可以做简单的校验，确保数据在传入范围内是合理的即可，如果是关键接口，调用频率极高，且对外开放，那就需要认真思考一下，该怎么做校验了。

注释规约

其他

这个还是很实用的，日后可能恢复的代码用三斜杠来描述。