所有pom文件中的依赖声明放在<dependencies>语句块中，所有版本仲裁放在<dependencyManagement>语句块中【说明：<dependencyManagement>里只是声明版本，并不实现引入，因此子项目需要显式的声明依赖，version和scope都读取自父pom。而<dependencies>所有声明在主pom的<dependencies>里的依赖都会自动引入，并默认被所有的子项目继承】
二方库不要有配置项，最低限度不要再增加配置项
为避免应用二方库的依赖冲突问题，二方库发布者应当遵循以下原则
1）精简可控原则。移除一切不必要的API和依赖，只包含Service API、必要的领域模型对象、Utils类、常量、枚举等
2）稳定可追溯原则。每个版本的变化应该被记录，二方库由谁维护，源码在哪里，都需要能方便查到
高并发服务器建议调小TCP协议的time_wait超时时间【操作系统默认240秒后，才会关闭处于time_wait状态的连接，在高并发访问下，服务器端会因为处于time_wait的连接数太多，可能无法建立新的连接，所以需要在服务器上调小此等待值】
正例：在linux服务器上请通过变更/etc/sysctl.conf文件去修改该缺省值（秒）：net.ipv4.tcp_fin_timeout = 30
调大服务器所支持的最大文件句柄数（File Descriptor，简写为 fd）【说明：主流操作系统的设计是将TCP/UDP连接采用与文件一样的方式去管理，即一个连接对应于一个fd。主流的linux服务器默认所支持最大fd数量为1024，当并发连接数很大时很容易因为fd不足而出现“open too many files”错误，导致新的连接无法建立。建议将linux服务器所支持的最大句柄数调高数倍（与服务器的内存数量相关）】
给JVM环境参数设置-XX:+HeapDumpOnOutOfMemoryError参数，让JVM碰到
OOM场景时输出dump信息【说明：OOM的发生是有概率的，甚至相隔数月才出现一例，出错时的堆内信息对解决问题非常有帮助】
在线上生产环境，JVM的Xms和Xmx设置一样大小的内存容量，避免在GC后调整堆大小带来的压力
七、设计规约存储方案和数据结构需要认真地进行设计和评审
需求分析与系统设计在考虑主干功能的同时，需要充分评估异常流程与业务边界
谨慎使用继承的方式来进行扩展，优先使用聚合/组合的方式来实现
系统设计主要目的是明确需求、理顺逻辑、后期维护，次要目的用于指导编码。
设计的本质就是识别和表达系统难点，找到系统的变化点，并隔离变化点
系统架构设计的目的【1.确定系统边界。确定系统在技术层面上的做与不做；2.确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出； 3.确定指导后续设计与演化的原则。使后续的子系统或模块设计在规定的框架内继续演化；4.确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等】
个人小结以上内容便是我一边读，一边思考整理出来的。《Java开发手册》是实践开发中提炼出来的精华，当中有很多小点都是值得拿出来仔细推敲，往往小的规约背后隐藏着大学问。或许你和我一样，有些地方并不熟悉或者暂时并不理解为什么这样规约，个人觉得这些困惑的点读一遍、思考一遍远远不够，应该收藏下来，有空的时候多读、多思考。如果开发中遇到了手册中类似的场景，那么收获会更大，理解会更深。最后，正如手册中提到的愿景，“码出高效，码出质量”，希望你我都能码出一个新的高度。