Java读书笔记
目录
总览
Java编程基础
Java编程规范
设计模式（基于java实现）
重构，改善既有的代码的设计
Java web应用框架：Springboot
Java基础知识
Java基础语法
Java高级语法
Java高级特性
Java编程工具
Sublime Text
vim
IntelliJ IDEA
Java虚拟机
第一部分 走近java
走近java
第二部分 自动内存管理机制
Java内存区域与内存溢出异常
垃圾收集器与内存分配策略
虚拟机性能监控与故障处理工具
调优案例分析与实战
第三部分 虚拟机执行子系统
类文件结构
虚拟机类加载机制
虚拟机字节码执行引擎
类加载及执行子系统的案例与实战
第四部分 程序编译与代码优化
早期（编译器）优化
晚期（运行期）优化
第五部分 高效并发
Java内存模型与线程
线程安全与锁优化
Java虚拟机
Java编程规范
编程规约
命名风格
常量定义
代码格式
OOP规约
集合处理
并发处理
控制语句
注释规约
其他
异常日志
异常处理
日志规约
单元测试
安全规约
Mysql数据库
建表规约
索引规约
SQL语句
ORM映射
工程结构
应用分层
二方依赖库
服务器
软件建模与设计
UML类图
1. 泛化（Generalization）
【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。
【箭头指向】：带三角箭头的实线，箭头指向父类
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-546Mo1Hp-1614078282859)(media/24b53fd9d9b38eed8fb41d637461cb3f.png)]
2. 实现（Realization）
【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现.
【箭头指向】：带三角箭头的虚线，箭头指向接口
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HukTcRJu-1614078282861)(media/d7804708323a61859c602ee70f661abb.png)]
3. 关联（Association)
【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，
丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量
【箭头及指向】：带普通箭头的实心线，指向被拥有者
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aR8hpM1w-1614078282862)(media/8641d79c9e2070e8ed0e38cd8958fb74.png)]
上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。
但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。
下图为自身关联:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vRll2At5-1614078282863)(media/24df7a5e00e7545786cc6bae127f4d29.png)]
4. 聚合（Aggregation）
【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。
聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
【代码体现】：成员变量
【箭头及指向】：带空心菱形的实心线，菱形指向整体
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7hV2s15L-1614078282863)(media/a66145d66c34c67ad172e4b8c28e2139.png)]
5. 组合(Composition)
【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。
如公司和部门是整体和部分的关系，没有公司就不存在部门。
组合关系是关联关系的一种，是比聚合关系还要强的关系，
它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
【代码体现】：成员变量
【箭头及指向】：带实心菱形的实线，菱形指向整体
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XoOSu4ey-1614078282864)(media/a9005d9c756c4f1ea1db8e627c6ff9f2.png)]
6. 依赖(Dependency)
【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，
所以要尽量不使用双向的互相依赖.
【代码表现】：局部变量、方法的参数或者对静态方法的调用
【箭头及指向】：带箭头的虚线，指向被使用者
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FPdqtzUE-1614078282865)(media/43f13ae8abc1749dd8c4a64a15d8f374.png)]
7.类图集合关系
各种关系的强弱顺序：
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
下面这张UML图，比较形象地展示了各种类图关系：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7mjk8hsh-1614078282865)(media/36a85b46d203432f1d777402e1ae8109.png)]
类图绘制的要点
1类的操作是针对类自身的操作，而不是它去操作人家。比如书这个类有上架下架的操作，是书自己被上架下架，不能因为上架下架是管理员的动作而把它放在管理员的操作里。
2两个相关联的类，需要在关联的类中加上被关联类的ID，并且箭头指向被关联类。可以理解为数据表中的外键。比如借书和书，借书需要用到书的信息，因此借书类需包含书的ID，箭头指向书。
3由于业务复杂性，一个显示中的实体可能会被分为多个类，这是很正常的，类不是越少越好。类的设计取决于怎样让后台程序的操作更加简单。比如单看逻辑，借书类可以不存在，它的信息可以放在书这个类里。然而借还书和书的上架下架完全不是一回事，借书类对借书的操作更加方便，不需要去重复改动书这个类中的内容。此外，如果书和借书是1对多的关系，那就必须分为两个类。
4类图中的规范问题，比如不同关系需要不同的箭头，可见性符号等。
UML时序图
时序图（Sequence
Diagram）是显示对象之间交互的图，这些对象是按时间顺序排列的。顺序图中显示的是参与交互的对象及其对象之间消息交互的顺序。时序图中包括的建模元素主要有：角色(Actor)、对象（Actor）、生命线（Lifeline）、控制焦点（Activation）、消息（Message）、自关联消息、组合片段。
角色
系统角色，可以是人、及其甚至其他的系统或者子系统。
对象
对象包括三种命名方式：
第一种方式包括对象名和类名；
第二中方式只显示类名不显示对象名，即表示他是一个匿名对象；
第三种方式只显示对象名不显示类名。
生命线
生命线在顺序图中表示为从对象图标向下延伸的一条虚线，表示对象存在的时间。
控制焦点
控制焦点是顺序图中表示时间段的符号，在这个时间段内对象将执行相应的操作。用小矩形表示。
消息
消息一般分为同步消息（Synchronous Message），异步消息（Asynchronous
Message）和返回消息（Return Message）。
同步消息：消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息的接收者放弃或者返回控制。用来表示同步的意义。
异步消息：消息发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。
返回消息：返回消息表示从过程调用返回。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GJmYLL0a-1614078282866)(media/c88b4fb23da07dbc0db088a22462d51c.png)]
自关联消息
表示方法的自身调用或者一个对象内的一个方法调用另外一个方法。以一个半闭合的长方形+下方实心剪头表示。
UML时序图组合片段简要说明 ：
ref：引用其他地方定义的组合片段；
alt：在一组行为中根据特定的条件选择某个交互；
opt：表示一个可选的行为；
break：提供了和编程语言中的break类拟的机制；
par：支持交互片段的并发执行；
seq：强迫交互按照特定的顺序执行；
strict：明确定义了一组交互片段的执行顺序；
neg：用来标志不应该发生的交互；
region：标志在组合片段中先于其他交互片断发生的交互；
ignore：明确定义了交互片段不应该响应的消息；
consider：明确标志了应该被处理的消息
assert：标志了在交互片段中作为事件唯一的合法继续者的操作数；
loop：说明交互片段会被重复执行
例如：并行：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GrFctaQU-1614078282866)(media/28a1b9fe31872852ec5d491e3779afac.png)]
例如：循环
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vppqwFIT-1614078282866)(media/1b96d660ae7148d870a6e28f3fa8657f.png)]
Stay hungry，stay foolish ！
设计模式
创建型模式
抽象工厂（abstract factory）
生成器（Builder）
工厂方法（Factory）
原型（Prototype）
单例（Singleton）
结构型模式
适配器（adapter）
桥接（bridge）
组合（composite）
装饰（decorator）
外观（facade）
享元（flyweight）
代理（proxy）
行为型模式
责任链（chain of responsibility）
命令（command）
解释器（interpreter）
迭代器（Tterator）
中介者（mediator）
备忘录（mementor）
观察者（observer）
状态（state）
策略（strategy）
模板方法（template method）
访问者（visitor）
代码重构
引言
我该怎么开始介绍重构（refactoring）呢？按照传统作法，一开始介绍某个东西时，首先应该大致讲讲它的历史、主要原理等等。可是每当有人在会场上介绍这些东西，总是诱发我的瞌睡虫。我的思绪开始游荡，我的眼神开始迷离，直到他或她拿出实例，我才能够提起精神。实例之所以可以拯救我于太虚之中，因为它让我看见事情的真正行进。谈厚理，很容易流于泛泛，又很难说明如何实际应用。给出一个实例，
却可以帮助我把事情认识清楚。
所以我决定以一个实例作为本书起点。在此过程中我将告诉你很多重构原理，并且让你对重构过程有一点感觉。然后我才能向你提供普通惯见的原理介绍。
但是，面对这个介绍性实例，我遇到了一个大问题。如果我选择一个大型程序，对程序自身的描述和对重构过程的描述就太复杂了，任何读者都将无法掌握（我试了
一下，哪怕稍微复杂一点的例子都会超过100页）。如果我选择一个够小以至于容易理解的程序，又恐怕看不出重构的价值。
和任何想要介绍「应用于真实世界中的有用技术」的人一样，我陷入了一个十分典型的两难困境。我将带引你看看如何在一个我所选择的小程序中进行重构，然而坦白说，那个程序的规模根本不值得我们那么做。但是如果我给你看的代码是大系统的一部分，重构技术很快就变得重要起来。所以请你一边观赏这个小例子，一边想像它身处于一个大得多的系统。
为何重构
我不想把重构说成治百病的万灵丹，它绝对不是所谓的「银弹」[1]。不过它的确很有价值，虽不是一颗银子弹却是一把「银钳子」，可以帮助你始终良好地控制自己的代码。重构是个工具，它可以（并且应该）为了以下数个目的而被运用。
[1]译注：「银弹」（silver bullet）是美国家喻户晓的比喻。美国民间流传月圆之夜狼人
出没，只有以纯银子弹射穿狼人心脏，才能制服狼人。
「重构」改进软件设计
如果没有重构，程序的设计会逐渐腐败变质。当人们只为短期目的，或是在完全理解整体设计之前，就贸然修改代码，程序将逐渐失去自己的结构，程序员愈来愈难通过阅读源码而理解原本设计。重构很像是在整理代码，你所做的就是让所有东西回到应该的位置上。代码结构的流失是累积性的。愈难看出代码所代表的设计意涵，就愈难保护其中设计，于是该设计就腐败得愈快。经常性的重构可以帮助代码维持自己该有的形态。
同样完成一件事，设计不良的程序往往需要更多代码，这常常是因为代码在不同的地方使用完全相同的语句做同样的事。因此改进设计的一个重要方向就是消除重复代码（Duplicate
Code）。这个动作的重要性着眼于未来。代码数量减少并不会使系统运行更快，因为这对程序的运行轨迹几乎没有任何明显影响。然而代码数量减少将使未来可能的程序修改动作容易得多。代码愈多，正确的修改就愈困难，因为有更多代码需要理解。你在这儿做了点修改，系统却不如预期那样工作，因为你未曾修改另一处——那儿的代码做着几乎完全一样的事情，只是所处环境略有不同。
如果消除重复代码，你就可以确定代码将所有事物和行为都只表述一次，惟一一次，这正是优秀设计的根本。
「重构」使软件更易被理解
从许多角度来说，所谓程序设计，便是与计算机交谈。你编写代码告诉计算机做什么事，它的响应则是精确按照你的指示行动。你得及时填补「想要它做什么」和「告
诉它做什么」之间的缝隙。这种编程模式的核心就是「准确说出吾人所欲」。除了计算机外，你的源码还有其他读者：数个月之后可能会有另一位程序员尝试读懂你的代码并做一些修改。我们很容易忘记这第二位读者，但他才是最重要的。计算机是否多花了数个钟头进行编译，又有什么关系呢？如果一个程序员花费一周时间来修改某段代码，那才关系重大——如果他理解你的代码，这个修改原本只需一小时。
问题在于，当你努力让程序运转的时候，你不会想到未来出现的那个开发者。是的，是应该改变一下我们的开发节奏，对代码做适当修改，让代码变得更易理解。重构可以帮助我们让代码更易读。一开始进行重构时，你的代码可以正常运行，但结构不够理想。在重构上花一点点时间，就可以让代码更好地表达自己的用途。这种编程模式的核心就是「准确说出你的意思」。
关于这一点，我没必要表现得如此无私。很多时候那个「未来的开发者」就是我自己。此时重构就显得尤其重要了。我是个很懒惰的程序员，我的懒惰表现形式之一就是：总是记不住自己写过的代码。事实上对于任何立可查阅的东西我都故意不去记它，因为我怕把自己的脑袋塞爆。我总是尽量把该记住的东西写进程序里头，这样我就不必记住它了。这么一来我就不必太担心Old
Peculier(译注：一种有名的麦芽酒〉[Jackson]杀光我的脑细胞。
这种可理解性还有另一方面的作用。我利用重构来协助我理解不熟悉的代码。当我看到不熟悉的代码，我必须试着理解其用途。我先看两行代码,然后对自己说：『噢，
是的，它做了这些那些……』。有了重构这个强大武器在手，我不会满足于这么一点脑中体会。我会真正动手修改代码，让它更好地反映出我的理解，然后重新执行，看它是否仍然正常运作，以此检验我的理解是否正确。
一开始我所做的重构都像这样停留在细枝末节上。随着代码渐趋简洁，我发现自己可以看到一些以前看不到的设计层面的东西。如果不对代码做这些修改，也许我永远看不见它们，因为我的聪明才智不足以在脑子里把这一切都想像出来。Ralph
Johnson把这种「早期重构」描述为「擦掉窗户上的污垢，使你看得更远」。研究代码时我发现，重构把我带到更高的理解层次上。如果没有重构，我达不到这种层次。
代码的坏味道
现在，对于「重构如何运作」，你已经有了相当好的理解。但是知道How不代表
知道When。决定何时重构、何时停止和知道重构机制如何运转是一样重要的。
难题来了！解释「如何删除一个instance变量」或「如何产生一个class
hierarchy（阶层体系）」很容易，因为这些都是很简单的事情。但要解释「该在什么时候做这些动作」就没那么顺理成章了。除了露几手含混的编程美学（说实话，这就是咱
这些顾问常做的事），我还希望让某些东西更具说服力一些。
去苏黎士拜访Kent
Beck的时候，我正在为这个微妙的问题大伤脑筋。也许是因为受到刚出生的女儿的气味影响吧，他提出「用味道来形容重构时机」。『味道』，他说，『听起来是不是比含混的美学理论要好多了？』啊，是的。我们看过很多很
多代码，它们所属的项目从大获成功到奄奄一息都有。观察这些代码时，我们学会了从中找寻某些特定结构，这些结构指出（有时甚至就像尖叫呼喊）重构的可能性。（本章主词换成「我们」，是为了反映一个事实：Kent和我共同撰写本章。你应该可以看出我俩的文笔差异——插科打诨的部分是我写的，其余都是他的。〕
我们并不试图给你一个「重构为时晚矣」的精确衡量标准。从我们的经验看来，没有任何量度规矩比得上一个见识广博者的直觉。我们只会告诉你一些迹象，它会指出「这里有一个可使用重构解决的问题」。你必须培养出自己的判断力，学会判断一个class内有多少instance变量算是太大、一个函数内有多少行代码才算太长。
如果你无法确定该进行哪一种重构手法，请阅读本章内容和封底内页表格来寻找灵感。你可以阅读本章（或快速浏览封底内页表格〕来判断自己闻到的是什么味道，
然后再看看我们所建议的重构手法能否帮助你。也许这里所列的「臭味条款」和你所检测的不尽相符，但愿它们能够为你指引正确方向。
构筑测试体系
如果你想进行重构（refactoring），首要前提就是拥有一个可靠的测试环境。就算你够幸运，有一个可以自动进行重构的工具，你还是需要测试。而且短时间内不可能有任何工具可以为我们自动进行所有可能的重构。
我并不把这视为缺点。我发现，编写优良的测试程序，可以极大提高我的编程速度，即使不进行重构也一样如此。这让我很吃惊，也违反许多程序员的直觉，所以我有
必要解释一下这个现象。
扫一扫
375
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
