24 黑白灰，理解延迟分配的两面性
延迟分配
ArrayList
对于使用频率高的类的实现，微小的性能改进，都可以带来巨大的实用价值
局部变量占用的资源，也应该需要时再分配，资源的分配和它 的使用也要尽可能地靠近。
延迟初始化
不到需要的时候不进行初始化
内存与cpu之间的权衡
考虑线程安全
复杂的方法，只有必要时才使用
规范点
声明时初始化 除非资源消耗比较多
27 怎么编写可持续发展的代码？
增长对软件的要求，就是要有处理越来越多工作和越来越大规模的能力或者潜力。这种能 力，通常称之为可伸缩性
两种规模扩张方式
规模垂直扩张（scale in/out）
指的是提高同一个处理单元处理更多负载的能力
是规模水平 扩张（scale up/down）
通过增加更多的处理单元，来处理更多的负载。分布式系统、负载均衡、集群系统
状态数据
分布式数据库
分离无状态数据 单独提供服务
使用用户资源
把最基本的服务状态封装起来，利用客户端的缓存，实现无状态服务
小结
小心使用服务状态，编码时要考虑服务状态的规模水平扩张能力
28 怎么尽量“不写”代码？
不要重新发明轮子
复用
一般来说，当我们使用类似的代码或者类似的功能超过两次时，就应该考虑这样的代码是不是可以复用了
推进轮子的改进
有问题响应
不要重复多个轮子
该放手时就放手
烂代码没有明显问题就放手
命名规范、代码整理，这些都动不了代码的逻辑，是安全的修改
小结
- 要提高代码的复用比例，减少编码的绝对数量；
- 要复用外部的优质接口，并且推动它们的改进；
- 烂代码该放手时就放手，以免引起不必要的兼容问题
29 编写经济代码的检查清单
为什么使用经济代码？
提升用户体验
降低研发成本
降低运营成本
防范可用性攻击
怎么编写
避免过度设计
核心需求&&无效需求
迭代演进，有所主次
选择简单直观
选择最简单，最直观的解决方案
超越线程同步
不可变
异步编程
减少内存使用
减少实例数量&&尺寸
避免性能陷阱
JMH
规模扩张能力
垂直扩张&&水平扩张
经济代码的检查清单
如果有检查点没有通过，那么你在阅读代码的时候，就要集中注意力，深入分析；在设计和编写代码的时候，要花时间衡量、妥协、改进；在评审代码的时候，要问清楚为什么这么做，能不能
有所改进，并且给出合理的建议。
需求评审
需求是真实的客户需求吗？
要解决的问题真实存在吗？
需求具有普遍的意义吗？
这个需求到底有多重要？
需求能不能分解、简化？
需求的最小要求是什么？
这个需求能不能在下一个版本再实现？
设计评审
能使用现存的接口吗？
设计是不是简单、直观？
一个接口是不是只表示一件事情？
接口之间的依赖关系是不是明确？
接口的调用方式是不是方便、皮实？
接口的实现可以做到不可变吗？
接口是多线程安全的吗？
可以使用异步编程吗？
接口需不需要频繁地拷贝数据？
无状态数据和有状态数据需不需要分离？
有状态数据的处理是否支持规模水平扩张？
代码评审
有没有可以重用的代码？
新的代码是不是可以重用？
有没有使用不必要的实例？
原始数据类的使用是否恰当？
集合的操作是不是多线程安全？
集合是不是可以禁止修改？
实例的尺寸还有改进的空间吗？
需要使用延迟分配方案吗？
线程同步是不是必须的？
线程同步的阻塞时间可以更短吗？
多状态同步会不会引起死锁？
是不是可以避免频繁的对象创建、销毁？
是不是可以减少内存的分配、拷贝和释放频率？
静态的集合是否会造成内存泄漏？
长时间的缓存能不能及时清理？
系统的资源能不能安全地释放？
依赖哈希值的集合，储存的对象有没有实现 hashCode() 和 equals() 方法？
hashCode() 的实现，会不会产生撞车的哈希值？
代码的清理，有没有变更代码的逻辑？
小结
要尽早地考虑性能问题
性能的实践经验需要日积月累
30丨“代码经济篇”答疑汇总
“要有意识”是我们首先要获得的能力。大部分代码的问题，其实都是意识和见识带来的问题。
性能的监控、评测和分析
第一个常用的工具是 JMH
第二个常用的工具是性能回归测试 减少重复工作
。编写自动的回归测试代码
第三个就是找一款成熟的性能调试工具
NetBeans Profiler、JProfiler、Java Mission Control、Stackify Prefix
第四个办法就是用实时的性能监控工具
New Relic APM，Stackify Retrace
代码的尺寸，也是一个我们需要考量的重要指标
JDK 9 中，Java 开始支持模块化
签名数据太大，比如文件图片，占用内存大，使用流处理可以减少内存占用吗？
分配一个 2048 个字节的数 组，每次从文件中读取不多于 2048 个字节的数据
31 | 为什么安全的代码这么重要？
安全编码原则
- 清楚调用接口的行为
- 跨界的数据不可信任
大部分有效的安全攻击，都是发生在漏洞公布之后，修复版本升级之前。这一段时间，是最危险的一段时间
启示
1.不起眼的代码问题，也可以造成巨大的破坏; - 安全修复版本，一定要第一时间更新;
- 安全漏洞的破坏性，我们很难预料，每个人都可能是安全漏洞的受害者
小结 - 不起眼的小问题，也会有巨大的安全缺陷，造成难以估量的损失;
- 编写安全的代码，是我们必须要掌握的基础技能;
- 安全问题，既是技术问题，也是管理问题
32 | 如何评估代码的安全缺陷？
三个问题 - 有什么事情是你必须要做的？
- 哪些事情是只有你能做的?
- 哪些事情是别人可以帮你做的？
关注用户感受
在一个好的软件缺陷评估体系中，不是只有代码错误才会被关注，没有错误的代码，也可能存在 需要变更或者改进的“缺陷.从用户视角出发的 决策，可以让我们的时间使用得更有市场价值
优先级的灵活性
软件缺陷优先等级的定义是为了帮助我们更好地解用户的感受程度，以及安排时间和处理事情
管理好自己的时间
哪些重要 哪些可以别人协作
安全漏洞
重视
33 | 整数的运算有哪些安全威胁？
整数的陷阱
溢出
小技巧
比较运算，选择“比较小的数
限定数的范围，选择冗余的空间
检查数据溢出
抽象的数据一旦有了现实意义，便有了具体的现实约束，我们一定要考虑这些约束
很多问题和我们的习惯并不相符，要通过制度设置来减少由于人的固有缺陷带来的经常性问题
34 | 数组和集合，可变量的安全陷阱
在不同的时间、地点里，可变量可以发生变 化。如果编写代码时，意识不到不同时空里的变化，就会面临安全威胁
深拷贝 变量指向的内容发生了改变，对另外一个实例没有影响
浅拷贝 和原实例指向相同指针
可变量的传递，存在竞态危害的安全风险；
可变量局部化，是解决可变量竞态危害的一种常用办法
35 | 怎么处理敏感信息？
什么是敏感信息
个人
商业
授权，敏感信息谁能看
定义权限
定义权限的主体
定义权限的归属
异常信息可能携带敏感数据，导致敏感数据通过异常信息泄露。
小结 - 要建立主动保护敏感信息的意识；
- 要识别系统的敏感信息，并且对敏感信息采取必要的、特殊的处理。
36 继承有什么安全缺陷？
一个可扩展的类，子类和父类可能会相互影响，从而导致不可预知的行为。
涉及敏感信息的类，增加可扩展性不一定是个优先选项，要尽量避免父类或者子类的影响。
37 边界 信任的分水岭
检查外部数据的合法性
内存的分配和拷贝不该依赖于外部未校验的数据
公开接口输入输出的数据还要考虑变量传递带来的危害
38 对象序列化的危害
序列化不是一个有安全保障的技术，传输和拆解过程都有被攻击的风险
尽量避免敏感信息序列化
敏感信息序列化的处理方案
实现 writeObject
实现 writeReplace 使用序列化代理
实现 Externalizable 接口
39 怎么控制好代码的权力
最小的权力设计
模块化
接口的访问权限
越开放的权限越需要控制，越封闭的权限越容易维护
最小限度的授予
限制特权代码
特权代码要短小
40 规范 代码长治久安的基础
对于api接口的使用 要规范
api接口的定义要清晰简单，描述详实周到
对api接口的实现 一定要在规范许可范围内自由发挥，越是影响广泛的实现越不要逾越规范的界限
41 预案 代码的主动风险管理
一个好的设计 需要一个双引擎和降落伞
反复妥协，反复设计
42 纵深 代码安全的深度防御
43 编写安全代码清单
基本原则
清楚调用接口的行为
跨界的数据不可信任
最小授权
减少安全攻击面
44 清单
记住安全的编码原理
学习编程语言的编码规范及安全编码指南
跟踪 学习最新的安全编码进展
45 总结
不局限与代码的编写者
机会成本
672
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
