眯眯眼猫头鹰的小树杈

前言

这篇文章会帮助你使用Spring Boot Starter AOP实现AOP。我们会使用AspectJ实现四个不同的通知(advice)，并且新建一个自定义的注解来追踪方法的执行时间。

前言

任何一个写JAVA代码的程序员都是一名API设计师！无论是否与他人分享代码，代码都将被自己或是他人使用。因此，所有的JAVA开发者都应该了解一个好的API设计的基本内容。

一个好的API设计需要严谨的思考和大量的经验。幸运的是，我们可以从其它聪明的人如Ference Mihaly那里学习到这些。Ference Mihaly的博客启发了我写出这篇JAVA8 API附录。当我们设计Speedment API时，非常依赖他的清单（我建议所有人都阅读以下他的指南）。

从一开始就步入正轨是很重要的，因为一旦API发布以后，就等于对使用它的客户发出坚定的承诺。就像Joshua Bloch所说的那样：“公开的API是永恒的，就像钻石一样。你只有一次机会使其成为正确的设计，所以尽己所能”。一个精心设计的API使坚定而准确的承诺以及实现的高度灵活性结合在一起，并最终惠及API的的设计者和使用者。

为什么要使用清单？设计正确的API（比如，定义一组JAVA类的可见部分）比编写API背后进行真实操作的实现类要困难的多。这是极少数人才能掌握的艺术。使用清单可以使开发人员避免最明显的错误，从而成为一个更好的开发人员，并节约了大量的时间。

强烈建议API设计师从使用者的视角来优化代码的简洁性，易用性和一致性 - 而不是去考虑API的具体实现。同时，他们应该尽可能隐藏实现的细节。

前言

spring是一个用于创建web和企业应用的一个很流行的框架。和别的只关注于一点的框架不同，Spring框架通过投资并组合项目提供了大量的功能来满足现代的业务需求。

Spring提供了许多灵活的方式来配置bean，如XML，注解和JavaConfig。随着功能数量的增加，复杂度也提升了，导致Spring应用的配置变得单调乏味且容易出错。

Spring团队开发出SpringBoot来解决配置复杂的问题。

但是在深入了解SpringBoot之前，我们会快速了解一下Spring框架，看一看SpringBoot究竟试图解决什么问题。

在这篇文章中将会涉及：

• Spring框架概览
• 使用SpringMVC和JPA(Hibernate)的Web应用
• SpringBoot初体验
  阅读全文 »

前言

设计模式可能是博客圈最热门的话题之一。但是，用来说明每个设计模式的例子通常不是很形象。为了挽救这一点，这篇博客将用一个简单有效的例子来解释组合模式。

我们不会再重复解释这个模型的概念。唯一需要记住的是组合模式通常用在一个树结构的递归操作上。

前言

首先，这篇文章没有进行任何的日志功能的详细介绍，而是对日志提出了几种最佳实践。适合对日志记录有所了解的同学阅读。
下面是正文：

JAVA日志管理既是一门科学，又是一门艺术。科学的部分是指了解写日志的工具以及其API，而选择日志的格式，消息的格式，日志记录的内容，哪种消息对应于哪一种日志级别，则完全是基于经验。从过去的实践证明，JAVA的日志记录会严重的影响性能。我也曾多次亲眼见到在DEBUG模式下运行的在线股票交易程序，比在WARN或是其它更高层次模式下运行时延时要严重的多。延时和速度是任何电子交易平台或是股票交易平台的一个重大关注点，所以我们必须了解并掌握JAVA日志及其最佳实践。这不仅仅只是为了用在金融或是投资银行领域，它适用于所有既追求速度又需要日志功能的应用。

为何需要日志

这是一个很基本的争议，人们会争辩说，我们可以使用System.out.println()来打印消息，为何还需要日志呢？每个人刚开始接触JAVA时，都使用System.out.println()在控制台打印消息。但是它的功能远远没有日志记录API如log4j或是java.util.logging强大。如果你正在写一个java服务器应用，那么你只有通过日志文件才能知道你的服务器在做什么。如果你没有记录任何日志，那么没有人知道你的服务器在干啥。而如果你的服务器作为一个中间件连接到应用中时，比如从股票交易系统或是电子交易系统获得输入流，将其转换并标准化后发送到输出流，这时日志就更为重要。没有日志你根本不知道究竟哪里出了问题。因此，日志在JAVA中是必不可少的。

前言

异常处理的问题之一是知道何时以及如何去使用它。我会讨论一些异常处理的最佳实践，也会总结最近在异常处理上的一些争论。

作为程序员，我们想要写高质量的能够解决问题的代码。但是，异常经常是伴随着代码产生的副作用。没有人喜欢副作用，因此我们会试图用自己的方式来解决这个问题。我看过不少的程序用下面的方法应对异常：

1
2
3
4
5
6
7

public void consumeAndForgetAllExceptions(){
    try {
        ...some code that throws exceptions
    } catch (Exception ex){
        ex.printStacktrace();
    }
}

上面这段代码的问题在哪里？

一旦一个异常被抛出之后，正常的执行流程会停止并且将控制交给捕捉块。捕捉块捕获异常，然后只是把它的信息打印了一下。之后程序正常运行，就像没有任何事情发生一样。

前言

这篇博客回顾JAVA8的CompletionStageAPI以及其在JAVA库中的标准实现CompletableFuture。将会通过几个例子来展示API的各种行为。

因为CompletableFuture是CompletionInterface接口的实现，所以我们首先要了解该接口的契约。它代表某个同步或异步计算的一个阶段。你可以把它理解为是一个为了产生有价值最终结果的计算的流水线上的一个单元。这意味着多个ComletionStage指令可以链接起来从而一个阶段的完成可以触发下一个阶段的执行。

除了实现了CompletionStage接口，Completion还继承了Future，这个接口用于实现一个未开始的异步事件。因为能够显式的完成Future，所以取名为CompletableFuture。

2000年的时候，Douglas Crockford声明JavaScript是最被误解的编程语言。这种误解来源于不良的命名规范，错误设计，非标准模式等等。因此，误解几乎是与之俱来的。

我也在关于Restful架构上发表了一个相似的意见：REST是世界上被误解最严重的架构模式。

事实上，大多人认为，创建一个RESTful API只需要基于URL和HTTP动词。这是完全错误的。

这个误解存在太久了。但是和JavaScript不同，REST规范讲述的非常清晰。它的命名本身就强调了状态的转化，但是这个概念却是所谓的RESTful API设计者们所最为忽视的。

如果你随便问十个开发者，他们的API是否支持HATEOAS，至少九个人会睁大双眼回答：你到底在说啥？

CAP定理是用来提醒设计师在设计联网的共享数据系统时需要作出的权衡。CAP理论影响了很多分布式数据系统的设计。这几年来，CAP一直被广泛的误解为是用于对数据库进行分类的工具。也流传着许多关于CAP的错误的信息。很多关于CAP博客的观点极有可能是错误的。

你需要进一步的了解CAP从而去分辨出关于CAP的错误的信息。

CAP定理适用于存储状态的分布式系统。在2000年的PODC上，Eric Brewer推测在任何联网的数据共享系统中，一致性、可用性和分区容忍性之间本质上存在折中。在2002年，MIT的Seth Gilbert和Nancy Lynch发表了对Eric Brewer推论的证明。这个理论说明网络数据共享系统只能确保或是强有力的支持一下三个属性中的两个：

• 一致性：确保分布式集群中的每一个节点都返回相同的，最近成功写入的数据。一致性意味着客户对数据的视图是一样的。有各种各样的一致性模型。而CAP中的一致性是指线性化或是顺序一致性，这是一种强一致性。
• 可用性：每一个非故障节点能够在一定时间内对客户端的请求作出相应。这里的重点在于每一个。为了实现可用性，在任意一个网络分区的节点都必须能够在一定时间内作出响应。
• 分区容忍性：尽管存在网络分区，但是系统依然能够继续运行并且保证一致性。网络分区已经成了生活中的常态。实现分区容忍性的分布式系统能够保证分区能够正常的从故障中恢复。

前言

这篇文章探索了现有的各种JAVA缓存基数，它们对各种场景下提高应用的性能起着重要的作用。

近十年来，信息技术极高的提升了业务流程，它已经成为了全球企业的战略性方案。它从“可有可无”演变到现在的“不可或缺”。因此，响应时间变得越发的重要。数据获取时间对用户体验影响极大，它在所有的商业应用中几乎都是关键性需求。影响响应时间的因素很多，包括网络管道，协议，硬件，软件以及网速。庞大的IT基础设施和苛刻的系统性能要求严重影响了任何组织的战略目标。

本文旨在强调通过Java缓存机制提升应用的性能。