gRPC

Define your service using Protocol Buffers, a powerful binary serialization toolset and language

gRPC是基于Protobuf开发的RPC框架，简化了protobuf的开发，提供了服务端和客户端网络交互这一块的代码。

Demo

照着 https://grpc.io/docs/quickstart/java.html 测试一下官方的Demo。

记得要把Update a gRPC service部分做了。

Thrift

• Thrift最初由Facebook研发，主要用于各个服务之间的RPC通信，支持跨语言，常用的语言比如C++，Java，Python，PHP，Ruby，Erlang，Perl，Haskell，C#，Cocoa，JavaScript，Node.js，SmallTalk and OCaml都支持。
• Thrift是一个典型的CS（客户端/服务端）结构，客户端和服务端可以使用不同语言开发。既然客户端和服务端能使用不同的语言开发，那么一定就要有一种中间语言来关联客户端和服务端的语言，这种语言就是IDL（Interface Description Language）。
• Thrift不支持无符号类型，因为很多变成语言不存在无符号类型，比如Java

Thrift数据类型

• byte：有符号字节
• i16：16位有符号整数
• i32：32位有符号整数
• i64：64位有符号整数
• double：64位有符号整数
• double：64位浮点数
• string：字符串

Google Protobuf

https://developers.google.com/protocol-buffers/

接下来看一下Google Protobuf的使用方式。Protobuf的主要作用是用来进行RPC的传输。它跟Apache Thrift属于同一个领域的框架，都可以用来序列化和反序列化数据进行传输。

RMI介绍

目前Java中有一门比较成熟，同时也是EJB的标准的技术叫做RMI(remote method invocation)。RMI限制了只能基于Java调用。这种跨机器的调用，是客户端序列化后字节码再通过网络进行传输到服务端，服务端再反序列化数据进行代码调用。这就涉及到2个概念，

随着互联网的发展，传统的HTTP协议已经很难满足Web应用日益复杂的需求了。近年来，随着HTML5的诞生，WebSocket协议被提出，它实现了浏览器与服务器的全双工通信，扩展了浏览器与服务端的通信功能，使服务端也能主动向客户端发送数据。

　　我们知道，传统的HTTP协议是无状态的，每次请求（request）都要由客户端（如 浏览器）主动发起，服务端进行处理后返回response结果，而服务端很难主动向客户端发送数据；这种客户端是主动方，服务端是被动方的传统Web模式 对于信息变化不频繁的Web应用来说造成的麻烦较小，而对于涉及实时信息的Web应用却带来了很大的不便，如带有即时通信、实时数据、订阅推送等功能的应用。在WebSocket规范提出之前，开发人员若要实现这些实时性较强的功能，经常会使用折衷的解决方法：轮询（polling）和Comet技术。其实后者本质上也是一种轮询，只不过有所改进。 　　

Netty

简介

http://netty.io

Netty is an asynchronous event-driven network application framework
for rapid development of maintainable high performance protocol servers & clients.

本系列源码在
https://github.com/sail-y/netty

Netty能做什么？

1. 可以像tomcat一样做一个http服务器。
2. socket开发。
3. 支持长连接开发，例如websocket。

Java 8日期/时间（ Date/Time）API是开发人员最受追捧的变化之一，Java从一开始就没有对日期时间处理的一致性方法，因此日期/时间API也是除Java核心API以外另一项倍受欢迎的内容。

为什么我们需要新的Java日期/时间API？

在开始研究Java 8日期/时间API之前，让我们先来看一下为什么我们需要这样一个新的API。在Java中，现有的与日期和时间相关的类存在诸多问题，其中有：

1. Java的日期/时间类的定义并不一致，在java.util和java.sql的包中都有日期类，此外用于格式化和解析的类在java.text包中定义。
2. java.util.Date同时包含日期和时间，而java.sql.Date仅包含日期，将其纳入java.sql包并不合理。另外这两个类都有相同的名字，这本身就是一个非常糟糕的设计。
3. 对于时间、时间戳、格式化以及解析，并没有一些明确定义的类。对于格式化和解析的需求，我们有java.text.DateFormat抽象类，但通常情况下，SimpleDateFormat类被用于此类需求。
4. 所有的日期类都是可变的，因此他们都不是线程安全的，这是Java日期类最大的问题之一。
5. 日期类并不提供国际化，没有时区支持，因此Java引入了java.util.Calendar和java.util.TimeZone类，但他们同样存在上述所有的问题。

这篇文章发现别人写的好货，直接转过来看看。
http://www.cnblogs.com/CarpenterLee/archive/2017/03/28/6637118.html

Stream Pipelines

前面我们已经学会如何使用Stream API，用起来真的很爽，但简洁的方法下面似乎隐藏着无尽的秘密，如此强大的API是如何实现的呢？比如Pipeline是怎么执行的，每次方法调用都会导致一次迭代吗？自动并行又是怎么做到的，线程个数是多少？本节我们学习Stream流水线的原理，这是Stream实现的关键所在。

首先回顾一下容器执行Lambda表达式的方式，以ArrayList.forEach()方法为例，具体代码如下：

Collectors静态工厂类

对于Collectors静态工厂类来说，其实现一共分为两种情况：

1. 通过CollectorImpl来实现。
2. 通过reducing方法来实现, reducing方法本身又是通过CollectorImpl实现的。

自定义收集器

之前我们简单说过了Collector接口，以及他的简单使用，现在我们来尝试自定义一个收集器，来进行更加深刻的理解。

Collector的5个方法：

1
2
3
4
5
6
7
8
9

Supplier<A> supplier();    
BiConsumer<A, T> accumulator();
BinaryOperator<A> combiner();
Function<A, R> finisher();
// 收集器特性，只有3个值，CONCURRENT，UNORDERED，IDENTITY_FINISH
// CONCURRENT标识同一个结果容器可以由多个线程多次调用。
// UNORDERED标识收集器并不承诺保证流的顺序。
// IDENTITY_FINISH标识finisher函数就是identity函数。
Set<Characteristics> characteristics();

比较器详解

关于比较器我们经常在排序的时候用到，按照某个属性排序。比如我们按照学生的成绩排序，如果成绩相等呢，我们再按照姓名排序。

在Java 8中，Comparator新增了不少默认方法以及静态方法，我们要把这些东西用起来。