Java代码安全规范

本文目的
故障分析
资源分析
安全条目
- QPS
- CPU
- Memory
- 磁盘I/O
- Network
- 代码工程
- Web安全
附录
- Redis网卡打满参照表
参考

本文目的

向Nasa的《NASA的10条代码编写原则》学习，目的有二：一是约束Java代码的使用、规避较高危的代码，二是code review更易识别。有很多优秀的JAVA规范、如《阿里巴巴JAVA开发手册》等都介绍了编码的一些原则、编程风格等，本文不再赘述；这里更多介绍生产环境易出故障的javacode。

提高生产环境系统的稳定性、可用性并非代码一项，需要有一套结构化的体系、从系统运营角度去通盘考虑；代码是系统基石之一。

故障分析

代码危险程度很难量化分析，从生产环境的故障着手分析。笔者统计了新美大近两年半对交易额有较大损失影响的线上S1故障（日交易额影响比大于5%），发现WEB服务影响最大的是DB、其次CACHE，还有些重复打款、zk重连、专线故障、前端轮询、内存不足、LOG问题等，比较共性的是：资源层级越底层、对交易额的损失越大。因此代码危险程度可以从代码对资源影响程度去衡量。

资源分析

Nasa的编写原则面向航空场景的C语言，与互联网WEB场景相比、1）服务远程通讯更少2）偏硬件打交道得多，对低能耗和安全的要求比较高，既非cpu密集型、也非io密集型 3）代码工程浩大。因此Nasa主要集中在mem及代码工程上。NASA规范总结有3条：限制内存动态分配、限制指针层级、优化C编译器做集成和静态检查。

互联网WEB场景，普通service属于cpu密集型，cpu及network资源容易出现瓶颈；而像mysql、redis等存储系统对碰盘i/o、cpu、network的要求都很高。JAVA耻笑自动档内存的C、JVM在解放程序猿对内存管理的同时，也因将内存管理交给了JVM、比C更容易出现不明所以的故障，当你越不了解它、也就越难真正驾驭它。本文主要针对JAVA互联网WEB、规范单机的三处资源：内存、CPU、网络。

本文分类的原则、是从java单机的视角去看待资源（cpu、mem、i/o、network），例如mysql的吐吞率大的sql归在Network资源方面。

安全条目

QPS

JOB、MQ、RPC（写入场景及读QPS较高场景）需要限制请求QPS及响应队列，以便保护Write及Read资源。
论询导致后台QPS过大，QPS可能超出人预期的几倍、甚至上百倍；建议有专门的长链集群。
活动Push、大促、秒杀类活动导致后台QPS过大，后端服务容量常被打满、甚至压垮下游核心服务；建议有专门的活动运营机制隔离此类应用场景。

CPU

Future、RPC、Redis、Http Connection、MySQL Connection等远程调用必需明确设置Network Timeout Time，防止造成线程积压、增加cpu负载。
大对象、大集合的序列化耗时明显。几个思路：集合拆分与并行处理、byte代替明文存储、选择合适的序列化协议和框架。

Memory

禁止使用无界的List与Map集合、必须限制MaxSize，防止堆泄漏、FGC。
Local Cache、Buffer(MQ、Log、Thrift)、Thread Local等必需明确限制MaxSzie，防止引发FullGC及OOM。（本质是无界集合、突出local cache&buffer的使用场景）
禁止使用自定义线程池、提供统一线程池解决方案(监控、分布式限流、动态调整线程池大小、回收thread local)，防止应用线程池失去监管、带来潜在危害（在方法区动态创建thread pool属于常见错误之一）
在线程池的场景下使用Thread Local在回收前需要一个兜底清除的节制，防止线程复用Thread Local反复使用的风险
禁止JOB一次性全量操作、必须取一批、处理一批，防止引发潜在的堆溢出问题
慎用DirectBuffer、注意内存泄漏风险（Netty i/o线程及业务线程）XX:MaxDirectMemorySize=1g
慎用大对象，防止出现FGC、System Load过高、热点TPS过大

磁盘I/O

禁止线上应用出现swap，防止产生I/O中断、秒级GC等风险，JVM明确swap size。出现swap建议深入排查原因看是否需要更换物理机

Network

批量SQL必须Limit限制最大记录条数，防止产生Big Sql、影响MySQL连接数及吞吐率
大表操作场景。禁止大表Join、select count分页方式，慎用order by与where查询场景，避免产生慢SQL、拖累MySQL性能。分页可用id偏移的方式代替"limit n,m"。
不准Redis对象超过4KB，防止热点KeyValue TPS过高、引发性能问题
建议提供统一封装的HttpClient解决方案，防止连接池反复创建、未关闭连接、未设置超时时间、无访问链路监控等风险。

· 服务器TCP连接出现大量的TIME_WAIT、CLOSE_WAIT，占用大量fd、导致服务器不可用。优化思路大体是调整保活机制、快速回收，线上故障通过重启机器解决此类问题。

代码工程

不准单类超过1000行代码，防止功能模块耦合、带来不可预知的代码修改危害。

Web安全

OWASP TOP 10-2017（全球WEB安全10大安全问题排行榜）：

A1-Injection
A2-Broken Authentication and Session Management
A3-Cross-Site Scripting (XSS)
A4-Broken Access Control
A5-Security Misconfiguration
A6-Sensitive Data Exposure
A7-Insufficient Attack Protection
A8-Cross-Site Request Forgery (CSRF)
A9-Using Components with Known Vulnerabilities
A10-Underprotected APIs

更多细节请详细访问：https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

附录

Redis网卡打满参照表

当热点key的QPS超过一定阈值会出现网卡打满的情况。现在redis集群是万兆网卡（10000Mbps），对照表如下：

传输对象平均大小	打满万兆网卡的qps	打满千兆网卡的qps	备注
1KB	128w/s	12.8w/s
2KB	64w/s	6.4w/s
4KB	32w/s	4.2w/s
8KB	16w/s	1.6w/s
16KB	8w/s	8k/s
32KB	4w/s	4k/s
64KB	2w/s	2k/s
128KB	1w/s	1k/s
256KB	5k/s	500/s
512KB	2.5k/s	250/s