吴声子夜歌的博客

这么来说吧，在工厂的流水线上，工人的任务是过来一个零件就把它安装在规定的位置上，而技术人员的任务则是确定零件的尺寸、材料、安装位置等，而且一旦出现问题，技术人员还要能够查明出现问题的原因，并且提出解决办法，我们Javaer也应该是这样的，这就需要我们逐步培养自己，在提高自己技能的同时也提高自己的思维方式，以下20条建议可以逐步把我们向技术人员方向培养。这也算是IDE的便利性造成的习惯，一个业务类不进行抽象，直接进行编码，在需要修改时，要么依靠IDE批量重构，要么通过查找替换的方式重构，很方便，不是吗？

我们经常会看到一个项目的lib中包含了大量的工具、框架包，要想看懂项目代码还应该对这些工具包有一个大致的了解，开源工具包确实会对我们的项目有非常大的帮助，比如提升代码质量，减少Bug产生，降低工作量等，但一旦项目中的工具杂乱无章时就会产生依赖的无序性，这会导致代码中隐藏着炸弹，不知何时就会突然引爆了。对于开源工具，我们应该大胆采用，仔细筛选，如果确实所有的开源工具都无法满足我们的需求，那就自己开发一个开源项目，为千千万万的Java人服务，也为Java的生态系统贡献自己的力量。

（1）性能衡量标准是技术与业务之间的契约“非常快”是一个直观性的描述，它不具有衡量的可能性，对技术人员来说，一个请求在2秒钟之内响应就可以认为是“非常快”了，但对业务人员来说，​“非常快”指的是在0.5秒内看到结果—看，出现偏差了。如果我们不解决这种偏差，就有可能出现当技术人员认为优化结束的时候，而业务人员还认为系统很慢，仍然需要提高继续性能，于是拒不签收验收文档，这就产生商务麻烦了。（2）性能衡量标志是技术优化的目标。

好办，任务排队，corePoolSize数量的工人不停歇地处理任务，新增加的任务按照一定的规则存放在仓库中（也就是我们的workQueue中）​，一旦任务增加的速度超过了工人处理的能力，也就是说仓库爆满时，车间就会继续招聘工人（也就是扩大线程数）​，直至工人数量达到maximumPoolSize为止，那如果所有的maximumPoolSize工人都在处理任务，而且仓库也是饱和状态，新增任务的该怎么处理呢？上面在加入元素时，如果判断出当前队列已满，则返回false，表示插入失败，之后再包装成队列满异常。

这段代码的逻辑是这样的：子线程是一个匿名内部类，它的run方法在执行时会休眠1秒钟，然后再执行后续的逻辑，而主线程则是休眠0.1秒后终止子线程的运行，也就是说，JVM在执行thread.stop()时，子线程还在执行sleep(1000)，此时stop方法会清除栈内信息，结束该线程，这也就导致了run方法的逻辑不完整，输出语句println代表的是一段逻辑，可能非常重要，比如子线程的主逻辑、资源回收、情景初始化等，但是因为stop线程了，这些就都不再执行，于是就产生了业务逻辑不完整的情况。

我们知道异常是主逻辑的例外逻辑，举个简单例子来说，比如我在马路上走（这是主逻辑）​，突然开过一辆车，我要避让（这是受检异常，必须处理）​，继续走着，突然一架飞机从我头顶飞过（非受检异常）​，我可以选择继续行走（不捕捉）​，也可以选择指责其噪音污染（捕捉，主逻辑的补充处理）​，再继续走着，突然一颗流星砸下来，这没有选择，属于错误，不能做任何处理。你自己看着办吧”​。我们知道，一个系统友好性的标志是用户对该系统的“粘性”​，粘性越高，系统越友好，粘性越低系统友好性越差，那问题是怎么提高系统的“粘性”呢？

在默认情况下所有方法的返回值都是空的，是的，虽然代理已经实现了它，但是没有任何的逻辑含义，那怎么办？虽然以上代码可以动态加载一个数组类，但是这没有任何意义，因为它不能生成一个数组对象，也就是说以上代码只是把一个String类型的数组类和long类型的数组类加载到了内存中（如果内存中没有该类的话）​，并不能通过newInstance方法生成一个实例对象，因为它没有定义数组的长度，在Java中数组是定长的，没有长度的数组是不允许存在的。我已将这种方式使用在多个项目中了，目前没有出现因为该反射引起的性能问题。

Java泛型（Generic）的引入加强了参数类型的安全性，减少了类型的转换，它与C++中的模板（Templates）比较类似，但是有一点不同的是：Java的泛型在编译期有效，在运行期被删除，也就是说所有的泛型参数类型在编译后都会被清除掉，我们来看一个例子，代码如下：程序很简单，编写了4个方法，arrayMethod方法接收String数组和Integer数组，这是一个典型的重载，listMethod接收元素类型为String和Integer的List变量。现在的问题是，这段程序是否能编译？如果不能，问题

常量声明是每一个项目都不可或缺的，在Java 1.5之前，我们只有两种方式的声明：类常量和接口常量，若在项目中使用的是Java 1.5之前的版本基本上都是如此定义的。这是一个简单的枚举常量命名，清晰又简单。顺便提一句，JLS（Java Language Specification，Java语言规范）提倡枚举项全部大写，字母之间用下划线分隔，这也是从常量的角度考虑的（当然，使用类似类名的命名方式也是比较友好的）​。可能有读者要问了：枚举常量与我们经常使用的类常量和静态常量相比有什么优势？

前面说了，subList生成的子列表是原列表的一个视图，那在subList执行完后，如果修改了原列表的内容会怎样呢？视图是否会改变呢？如果是数据库视图，表数据变更了，视图当然会变了，至于subList生成的视图是否会改变，还是从源码上来看吧，代码如下：程序中有一个原始列表，生成了一个子列表，然后在原始列表中增加一个元素，最后打印出原始列表和子列表的长度，大家想一下，这段程序什么地方会出现错误呢？list.add(“D”)会报错吗？不会，subList并没有锁定原列表，原列表当然可以继续修改。难道有两个si

数组在实际的系统开发中用得越来越少了，我们通常只有在阅读一些开源项目时才会看到它们的身影，在Java中它确实没有List、Set、Map这些集合类用起来方便，但是在基本类型处理方面，数组还是占优势的，而且集合类的底层也都是通过数组实现的，比如对一个数据集求和这样的计算：对一个int类型的数组求和，取出所有的数组元素并相加，此算法中如果是基本类型则使用数组效率是最高的，使用集合则效率次之。再看使用List求和：注意看加粗字体，这里其实已经做了一个拆箱动作，Integer对象通过intValue方法自动转换

因为String字符串是程序中最经常使用的类型）​，于是就设计了一个字符串池（也有叫做字符串常量池，String Pool或String Constant Pool 或String Literal Pool）​，在字符串池中所容纳的都是String字符串对象，它的创建机制是这样的：创建一个字符串时，首先检查池中是否有字面值相等的字符串，如果有，则不再创建，直接返回池中该对象的引用，若没有则创建之，然后放到池中，并返回新建对象的引用，这个池和我们平常所说的池概念非常相似。”的字符串查找，你是不是要崩溃了？

之所以危险，是因为System.gc要停止所有的响应（Stopthe world）​，才能检查内存中是否有可回收的对象，这对一个应用系统来说风险极大，如果是一个We b应用，所有的请求都会暂停，等待垃圾回收器执行完毕，若此时堆内存（Heap）中的对象少的话则还可以接受，一旦对象较多（现在的Web项目是越做越大，框架、工具也越来越多，加载到内存中的对象当然也就更多了）​，那这个过程就非常耗时了，可能0.01秒，也可能是1秒，甚至是20秒，这就会严重影响到业务的正常运行。怎么回事，小儿子的父亲也成了“干爹”?

哎，好像不对呀，如果编译器把构造代码块插入到各个构造函数中，那带有String形参的构造函数可就有问题，它会调用无参构造，那通过它生成Base对象时就会执行两次构造代码块：一次是由无参构造函数调用构造代码块，一次是执行自身的构造代码块，这样的话计算可就不准确了，main函数实际在内存中产生了3个对象，但结果却会是4。子类实例化时，会首先初始化父类（注意这里是初始化，可不是生成父类对象）​，也就是初始化父类的变量，调用父类的构造函数，然后才会初始化子类的变量，调用子类自己的构造函数，最后生成一个实例对象。

这就没招了，太基础了）​，我们发现0.4不能使用二进制准确的表示，在二进制数世界里它是一个无限循环的小数，也就是说，​“展示”都不能“展示”​，更别说是在内存中存储了（浮点数的存储包括三部分：符号位、指数位、尾数，具体不再介绍）​，可以这样理解，在十进制的世界里没有办法准确表示1/3，那在二进制世界里当然也无法准确表示1/5（如果二进制也有分数的话倒是可以表示）​，在二进制的世界里1/5是一个无限循环小数。那就对了，它是int类型的最大值，没错，有人输入了一个最大值，使校验条件失效了，Why？

我们编写一个实现了Serializable接口（序列化标志接口）的类，Eclipse马上就会给一个黄色警告：需要增加一个Serial Version ID。为什么要增加？它是怎么计算出来的？有什么用？本章就来解释该问题。类实现Serializable接口的目的是为了可持久化，比如网络传输或本地存储，为系统的分布和异构部署提供先决支持条件。若没有序列化，现在我们熟悉的远程调用、对象数据库都不可能存在，我们来看一个简单的序列化类：这是一个简单JavaBean，实现了Serializable接口，可以在网络上传

包名全小写，类名首字母全大写，常量全部大写并用下划线分隔，变量采用驼峰命名法（Camel Case）命名等，这些都是最基本的Java编码规范，是每个Javaer都应熟知的规则，但是在变量的声明中要注意不要引入容易混淆的字母。尝试阅读如下代码，思考一下打印出的i等于多少：肯定有人会说：这么简单的例子还能出错？运行结果肯定是22！实践是检验真理的唯一标准，将其拷贝到Eclipse中，然后Run一下看看，或许你会很奇怪，结果是2，而不是22，难道是Eclipse的显示有问题，少了个“2”​？因为赋给变量i的数字

Table API和DataSet、DataStream关联密切，可以首先通过一个DataSet或DataStream创建出一个Table，然后调用类似Filter、Join、Select的关系型转换操作来转换为一个新的Table对象，最后将一个Table对象转换为一个DataSet或DataStream并将结果输出。Flink处理批量数据的流程为：Flink系统内部将接收的数据转换成DataSet数据集，然后将DataSet数据集并行分布在集群的每个节点上；常用的Flink数据输出操作如表所示。

Flink由Job Manager、Task Manager和客户端组成。Job Manager是管理节点，负责集群任务的提交、分配和资源管理；Task Manager是具体执行任务的计算节点；客户端用于作业的提交。事件驱动模型是基于事件流的有状态的计算模型。它接收源源不断的事件，并根据事件的不同类型更新不同状态来触发不同计算。

Spark Streaming基于Spark API的流式计算扩展，它实现了一个高吞吐量、高容错的流式计算引擎。SparkStreaming从多种数据源获取数据（如Kafka、Flume、Kinesis、TCP等）​，在获取数据后使用高级函数（如map、reduce、join、window）组成的计算逻辑单元进行数据处理，最终将处理后的数据实时推送到消息服务、文件系统、数据库等。除了基本的流式计算，应用程序还可以在数据流上应用Spark的机器学习和图形处理算法。Spark Streaming的流程如图所示。

RDD是Spark中最基本的数据抽象，代表一个不可变、可分区、元素可并行计算的集合。RDD具有自动容错、位置感知性调度和可伸缩等特点。RDD允许用户在执行多个查询时显式地将数据集缓存在内存中，后续查询能够重用该数据集，这极大地提升了查询效率。Spark API依赖driver程序中的传递函数完成在集群上执行RDD转换并完成数据计算。在Java API中，函数所在的类需要实现org.apache.spark.api.java.function包中的接口。Spark提供了下面两种创建函数的方式。

ElasticSearch的底层存储基于Lucene实现，Lucene是Apache软件基金的一个开源子项目，是一套全文检索引擎架构，提供了完整的文本分析引擎、数据查询引擎和数据索引引擎。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以便在目标系统中实现全文检索的功能，或者以Lucene为基础建立一套完整的全文检索引擎。ElasticSearch的事务日志文件为Translog，记录了所有与更新相关的事务操作日志（例如add/update/delete）​。

Cassandra虚拟节点的具体实现是：如果一条数据属于虚拟节点A，则在写入数据时会被同步写入虚拟节点B和虚拟节点C（这里假定Replica的数量是3）​，当虚拟节点A失效（其实是虚拟节点A对应的物理节点失效）时，系统会去下一个临近节点B读写冗余数据，因为B只是一个虚拟节点，系统需要在从虚拟节点和物理节点的映射关系中找到虚拟节点B对应的物理节点后，再进行读写，这是引入虚拟节点后的不同之处，就是多了一步二次映射的计算过程。为了解决数据分布不均的问题，一致性Hash引入了“虚拟节点”的概念。

其中，HBase Client为用户提供API操作，ZooKeeper负责HBase集群的管理，HMaster是集群的主节点，用于管理Region Server上数据的分配和节点的运行，同时接收客户端的请求并将请求分发到Region Server上，Region Server是数据具体的存储和计算节点，HDFS是HBase的底层数据存储引擎。HBase的数据更新指在原有的数据基础上新加一条数据并更新该数据的版本号，用户查询的时候默认查询最新的一条数据，也可以指定版本号查询数据。

MapReduce是Hadoop的分布式计算框架，MapReduce应用程序首先需要声明数据的输入和输出路径（一般为HDFS路径）​，然后实现接口或抽象类的Map和Reduce函数，最后加上作业配置（Job Configuration）​，就完成了MapReduce应用程序的构建。

在实际应用过程中，为了提高消息的吞吐量，应用程序可以将Topic的Partition设置为多个（Partition的个数也不宜太多，一般依据集群大小和Topic上的数据量来决定，Partition的个数不能超过Broker节点的个数）​。Kafka多个Consumer并发消费消息，如图所示，启动3个Consumer（因为Partition的个数为3，所以Consumer的个数也被设置为3）并发地消费TopicA上的消息，TopicA的数据以Partition的形式存储在3个Broker上。

ZooKeeper是一个分布式协调服务，其设计的初衷是为分布式软件提供一致性服务。ZooKeeper提供了一个类似Linux文件系统的树形结构，ZooKeeper的每个节点既可以是目录也可以是数据，同时，ZooKeeper提供了对每个节点的监控与通知机制。基于ZooKeeper的一致性服务，可以方便地实现分布式锁、分布式选举、服务发现和监控、配置中心等功能。ZooKeeper是一个基于主从复制的高可用集群，ZooKeeper的角色包括Leader、Follower、Observer。Leader是集群主节点

Netty是一个高性能的异步事件驱动的网络应用程序框架，主要用于客户端和服务端网络应用程序的快速搭建和开发。基于Netty API可以非常快速、方便地构建一个高性能的TCP或UDP的网络应用，不但极大地简化了网络编程的复杂度，还提高了网络应用程序的性能和稳定性。Netty支持多种网络通信协议，包括TCP、UDP、FTP、HTTP、SMTP等。

Zuul的Filter使用包括Filter的定义和注入两步，具体如下。（1）定义PreRequestFilter。PreRequestFilter在请求被路由之前调用，一般用于实现身份验证和资源审查等。具体实现如下。上述代码通过继承ZuulFilter实现了一个Zuul Filter，该Filter的类型为PRE_Type，表示在路由之前被执行，在run（​）方法体中对用户名进行验证，如果用户名合法则通过，如果不合法则抛出异常，程序逻辑转到Error流程。（2）注入PreRequestFilter。

服务提供者在启动的时候会将自身的服务地址状态上报Consul Server，服务消费者在每次发起请求时都要先从Consul Server获取可用的临时服务列表（该列表维护了可用的服务提供者的地址）​，再选择一个可用的服务提供者的地址进行服务调用。

Spring Cloud Config服务为外部配置（键值对或YAML）提供了基于HTTP的远程资源访问接口。服务端可以使用@EnableConfigServer注释开启配置中心的功能，声明该应用程序是一个配置中心服务。

Spring AOP通过面向切面技术将与业务无关却为业务模块所共用的逻辑代码封装起来，以提高代码的复用率，降低模块之间的耦合度。Spring AOP将应用分为核心关注点和横切关注点两个部分。业务处理流程为核心关注点，被业务所依赖的公共部分为横切关注点。横切关注点的特点是其行为经常发生在核心关注点的多处，而多处操作基本相似，比如权限认证、日志、事务。AOP的核心思想是将核心关注点和横切关注点分离开来，以降低模块耦合度。Spring AOP的主要应用场景如表所示。

Spring通过一个配置文件描述Bean和Bean之间的依赖关系，利用Java的反射功能实例化Bean并建立Bean之间的依赖关系。Spring的IoC容器在完成这些底层工作的基础上，还提供了Bean实例缓存管理、Bean生命周期管理、Bean实例代理、事件发布和资源装载等高级服务。

在使用命令模式时首先要定义一个命令接收和执行者Receiver，接着定义一个具体的命令ConcreteCommand实例，并将命令接收者实例设置到实例中，然后定义一个命令的调用者Invoker实例，并将命令实例设置到实例中，最后调用命令调用者的action()，将命令发送出去，在命令接收者收到数据后会执行相关命令，这样就完成了命令的调用。中介者模式又叫作调停模式，是迪米特法则的典型应用。同时，状态模式基于对象的状态将对象行为进行了明确的界定，减少了对象行为之间的相互依赖，方便系统的扩展和维护。

以上代码定义了迭代器接口Iterator的实现类ConcreteIterator，在ConcreteIterator中定义了Collection用于访问集合中的数据，pos用于记录当前迭代器遍历到的元素位置，同时实现了在Iterator接口中定义的方法previous()、next()和hasNext()，以完成具体的迭代器需要实现的基础功能。其中，办理业务的固定流程就是模板算法中的框架，它常常是不变的，由抽象类定义和实现，而具体办理的业务是可变的部分，通常交给子类去做具体的实现。

外观模式（Facade Pattern）也叫作门面模式，通过一个门面（Facade）向客户端提供一个访问系统的统一接口，客户端无须关心和知晓系统内部各子模块（系统）之间的复杂关系，其主要目的是降低访问拥有多个子系统的复杂系统的难度，简化客户端与其之间的接口。我们常用的JDBC和DriverManager就使用了桥接模式，JDBC在连接数据库时，在各个数据库之间进行切换而不需要修改代码，因为JDBC提供了统一的接口，每个数据库都提供了各自的实现，通过一个叫作数据库驱动的程序来桥接即可。

设计模式是人们经过长期编程经验总结出来的一种编程思想。随着软件工程的不断演进，针对不同的需求，新的设计模式不断被提出（比如大数据领域中这些年不断被大家认可的数据分片思想）​，但设计模式的原则不会变。基于设计模式的原则，我们可以使用已有的设计模式，也可以根据产品或项目的开发需求在现有的设计模式基础上组合、改造或重新设计自身的设计模式。设计模式有7个原则：单一职责原则、开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成/聚合复用原则、迪米特法则，接下来对这些原则一一进行讲解。

当我们需要频繁访问一些基本数据，比如用户信息、系统字典信息等热数据时，为了加快系统的访问速度，往往会选择把数据缓存在内存中，这样用户再次访问数据时直接从内存中获取数据即可，不用频繁查询数据库，这不但缩短了系统的访问时间，还有效降低了数据库的负载，具体流程如图所示。在用户有写请求数据时先将数据写入数据库，然后写入缓存，用户再次访问该数据时会尝试直接从缓存中获取，如果在缓存中没有找到数据，则从数据库中查询并将结果返回给用户，同时将查询结果缓存起来以方便下次查询。

和异步确保型不同的是，数据库B在写完之后将不再通知写状态到数据库A，如果因为网络或其他原因，在如图7-12所示的第4步没有接收到消息，则消息服务器将不断重试发送消息到读消息日志，如果经过N次重试后读消息日志还是没有接收到日志，则消息不再发送，这时会出现数据库A和数据库B数据不一致的情况。但是，如果事务B执行失败，事务B本身就回滚，这时事务A已被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作进行反操作，恢复到未执行前事务A的状态。其中，非叶子节点只有键值，叶子节点包含完整的数据，如图所示。

一般的负载均衡软件如LVS实现的功能只是对请求数据包的转发和传递，从负载均衡下的节点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户；但需要注意的是，这里探测到的响应速度是负载均衡设备到各个服务器之间的响应速度，并不完全代表客户端到服务器的响应速度，因此存在一定偏差。在大型分布式系统中，网络起着至关重要的作用，本章对常用的网络7层架构，以及TCP/IP、HTTP和CDN的原理做简单介绍，这是我们构建分布式系统所必须了解的，只有理解这些原理，才能设计出好的系统，并更有针对性地做系统架构调优。