在现代的Java应用程序中很少不用到集合类和数组。 可以对集合进行增，删，改，插， 统计(聚合aggregate)。 这些操作的概念在SQL操作上也会用到。 但是对集合的操作却没有像SQL那样方便简捷。 为什么我们不能实现一种类似SQL语句一样方便的编程方式呢， 去取代一遍又一遍loop遍历的方式处理集合和数组中的数据？
另外，对于大数据量的集合， 能不能充分利用多核的优势， 并行的处理？
Stream是就是这种处理数据的风格， 一种流式风格。 这种风格在其它语言中也有实现， 比如Javascript (Node.js stream)。
这种风格将要处理的元素集合看作一种流， 流在管道中传输， 并且可以在管道的节点上进行处理， 比如筛选， 排序，聚合等。
元素流在管道中经过中间操作（intermediate operation）的处理，最后由最终操作(terminal operation)得到前面处理的结果。

1
2
3

+--------------------+       +------+   +------+   +---+   +-------+
| stream of elements +-----> |filter+-> |sorted+-> |map+-> |collect|
+--------------------+       +------+   +------+   +---+   +-------+

一个简单的例子：

1
2
3
4
5
6

List<Integer> transactionsIds = 
widgets.stream()
             .filter(b -> b.getColor() == RED)
             .sorted((x,y) -> x.getWeight() - y.getWeight())
             .mapToInt(Widget::getWeight)
             .sum();

阅读全文

Gulp是一个构建工具， 功能类似grunt, 以及Java生态圈的ant, maven， gradle等。 其它的javascript生态圈的构建工具可以参考: List of JavaScript Build Tools
它采用了一种流式处理的方式， 编写起来简单直观。 相对于其它javascript构建工具， 母亲啊它的star数是仅次于grunt，流行度还是比较高的。
通过"代码优于配置" (code over configuration), 通过javascript编写构建任务， 充分利用javascript生态圈的组件， 可以实现简单灵活的任务管理。 通过node stream的方式，直接在内存中管道式处理流，不必缓存到硬盘上， 节省构建时间。

Gulp介绍请参考我转载的另一篇文章： Building With Gulp
另外有一篇很好的入门文章： Getting started with gulp, 繁体版, 简体中文硬翻版

从我的实践上来看， gulp要比grunt更好的管理构建过程。 编写简单，条理清晰，功能强大，学习无曲线。

Gulp是基于Node.js构建的，因此Gulp源文件和你用来定义任务的Gulp文件都被写进了JavaScript（或者CoffeeScript）里。 Gulp本身虽然不能完成很多任务，但它有大量插件可用，开发者可以访问插件页面或者在npm搜索gulpplugin或者gulpfriendly就能看到。例如，有些插件可以用来执行JSHint、编译CoffeeScript，执行Mocha测试，甚至更新版本号。现在有大约980个左右的插件可以使用。你可以到http://gulpjs.com/plugins/或者http://npmsearch.com/?q=keywords:gulpplugin查找所需的软件。
面对如此众多的插件， 想要全部了解并灵活运用它们几乎是不可能的事情。 实际开发中多参考别的项目的实现， 根据自己的需求寻找合适的插件， 总结并开发自己的插件， 逐步积累对gulp的认识。

本文列出常用的几个插件， 并在将来的开发中更新此文作为记录文档。 多个插件和grunt的插件功能类似。

阅读全文

Java NIO (JSR 51)定义了Java new I/O API，提案2000年提出,2002年正式发布。 JDK 1.4起包含了相应的API实现。
JAVA NIO2 (JSR 203)定义了更多的 New I/O APIs， 提案2003提出，直到2011年才发布， 最终在JDK 7中才实现。
JSR 203除了提供更多的文件系统操作API(包括可插拔的自定义的文件系统)， 还提供了对socket和文件的异步 I/O操作。 同时实现了JSR-51提案中的socket channel全部功能,包括对绑定， option配置的支持以及多播multicast的实现。

当前很多的项目还停留在JAVA NIO的实现上， 对JAVA AIO(asynchronous I/O)着墨不多。 本文整理了一些关于JAVA AIO的介绍，以及netty对AIO的支持。
以下内容只针对socket的I/O操作， 不涉及对文件的处理。

阅读全文

最近看到一些限流的文章，特地整理了一下相关的知识。
在早期的计算机领域，限流技术(time limiting)被用作控制网络接口收发通信数据的速率。 可以用来优化性能，减少延迟和提高带宽等。
现在在互联网领域，也借鉴了这个概念， 用来为服务控制请求的速率， 如果双十一的限流， 12306的抢票等。
即使在细粒度的软件架构中，也有类似的概念。 比如Java线程池可以用Bounded queues保存待执行的任务， 一旦超过queue的容量， 线程池可以根据配置的策略处理此请求。

阅读全文

互联网是由许多小型网络构成的，每个网络上都有许多主机，这样便构成了一个有层次的结构。IP地址在设计时就考虑到地址分配的层次特点，将每个IP地址都分割成网络号和主机号两部分，以便于IP地址的寻址操作。

子网掩码只有一个作用，就是将某个IP地址划分成网络地址和主机地址两部分。子网掩码的设定必须遵循一定的规则。与IP地址相同，子网掩码的长度也是32位，左边是网络位，用二进制数字“1”表示；右边是主机位，用二进制数字“0”表示。只有通过子网掩码，才能表明一台主机所在的子网与其他子网的关系，使网络正常工作。 1 的部分代表网络号，掩码为 0的部分代表主机号。其中 A类地址的默认子网掩码为 255.0.0.0；B类地址的默认子网掩码为 255.255.0.0；C类地址的默认子网掩码为：255.255.255.0。

同一个网络内的主机的IP地址与掩码 "AND"操作后的结果必然相同。

阅读全文

Java 7增加NIO multicast的支持， netty 4中也增加了对multicast的支持: Issue #216。
实际在使用中需要对环境和Netty的代码进行相应的配置。

阅读全文

再了解了Java 8 Lambda的一些基本概念和应用后， 我们会有这样的一个问题: Lambda表达式被编译成了什么？。 这是一个有趣的问题，涉及到JDK的具体的实现。 本文将介绍OpenJDK对Lambda表达式的转换细节， 读者可以了解Java 8 Lambda表达式背景知识。

阅读全文

Arjun Sreedharan写的内核编写教程。 超级简单。
目前写了两篇：
Kernel 101 – Let’s write a Kernel
Kernel 201 - Let’s write a Kernel with keyboard and screen support

国内也有人翻译了，如

• 内核代号101 — 动手写自己的内核
• 编写最简单的内核：HelloWorld

以下是我根据上面的文章整理的翻译。

阅读全文

以前经常谈论的Java对比c++的一个优势是Java中没有多继承的问题。 因为Java中子类只能继承(extends)单个父类， 尽管可以实现(implements)多个接口，但是接口中只有抽象方法，方法体是空的，没有具体的方法实现，不会有方法冲突的问题。

这些都是久远的说法了，自从今年Java 8发布后， 接口中也可以定义方法了(default method)。 之所以打破以前的设计在接口中
增加具体的方法， 是为了既有的成千上万的Java类库的类增加新的功能， 且不必对这些类重新进行设计。 比如， 只需在Collection接口中
增加default Stream<E> stream(), 相应的Set和List接口以及它们的子类都包含此的方法， 不必为每个子类都重新copy这个方法。

这是一个折衷的设计，带来的问题就是为Java引入了多继承的问题。 我们知道， 接口可以继承接口， 类可以继承类和实现接口。 一旦继承的类和实现的接口中有
相同签名的方法， 会出现什么样的状况呢？ 本文将探讨各种情况的多继承， 以便能清楚的理解Java多继承的规则。

阅读全文

函数式接口(Functional Interface)是Java 8对一类特殊类型的接口的称呼。 这类接口只定义了唯一的抽象方法的接口（除了隐含的Object对象的公共方法）， 因此最开始也就做SAM类型的接口（Single Abstract Method）。

为什么会单单从接口中定义出此类接口呢？ 原因是在Java Lambda的实现中， 开发组不想再为Lambda表达式单独定义一种特殊的Structural函数类型，称之为箭头类型（arrow type）， 依然想采用Java既有的类型系统(class, interface, method等)， 原因是增加一个结构化的函数类型会增加函数类型的复杂性，破坏既有的Java类型，并对成千上万的Java类库造成严重的影响。 权衡利弊， 因此最终还是利用SAM 接口作为 Lambda表达式的目标类型。

JDK中已有的一些接口本身就是函数式接口，如Runnable。 JDK 8中又增加了java.util.function包， 提供了常用的函数式接口。

函数式接口代表的一种契约， 一种对某个特定函数类型的契约。 在它出现的地方，实际期望一个符合契约要求的函数。 Lambda表达式不能脱离上下文而存在，它必须要有一个明确的目标类型，而这个目标类型就是某个函数式接口。

阅读全文