本文翻译自官方文档New and noteworthy in 4.0，

本文带你了解Netty 4.0的值得注意的改变和新特性，帮助你将应用程序从老的Netty迁移到最新的版本上。

阅读全文

原文: Netty之Java堆外内存扫盲贴, 作者: 江南白衣

Java的堆外内存本来是高贵而神秘的东西，只在一些缓存方案的收费企业版里出现。但自从用了Netty，就变成了天天打交道的事情，毕竟堆外内存能减少IO时的内存复制，不需要堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。

好在，Netty所用的堆外内存只是Java NIO的 DirectByteBuffer类，通读一次很快。还有一些sun.misc.*的类木有源码，要自己跑去OpenJdk那看个明白。

阅读全文

本文根据唐福林老师在“高可用架构”微信群所做的《股市风暴下的雪球架构改造经验分享》整理而成，转发请注明来自微信公众号ArchNotes。

唐福林，雪球首席架构师，负责雪球业务快速增长应对及服务性能与稳定架构优化工作。毕业于北京师范大学，硕士学位。之前曾任微博平台资深架构师，微博技术委员会成员。长期关注并从事互联网服务后端性能及稳定性架构优化工作。

阅读全文

当我们用Netty实现一个TCP client时，我们当然希望当连接断掉的时候Netty能够自动重连。
Netty Client有两种情况下需要重连：

1. Netty Client启动的时候需要重连
2. 在程序运行中连接断掉需要重连。

对于第一种情况，Netty的作者在stackoverflow上给出了解决方案，
对于第二种情况，Netty的例子uptime中实现了一种解决方案。

而Thomas在他的文章中提供了这两种方式的实现的例子。

阅读全文

最近应用在测试中出现Out Of Memory的问题， 通过jmap查看，发现JVM heap全用满了。
有很多工具可以查看JVM堆的信息， 收费的比如JProfiler， YourKit，免费的如Oracle JDK自带的visualvm, jhat和Eclipse MAT。
这个应用安装在一台AWS上，没有图形界面， 内存也比较小，想通过VNC远程桌面启动visualvm或者MAT不可能，通过jhat分析dump出来的snapshot(大约4.3G)也很慢，半天没有分析完毕，这种办法也放弃。
最后通过MAT的命令行工具分析了dump出来的snapshot,查找到OOM的元凶。

阅读全文

从平均情况来看，应用程序中String对象会消耗大量的内存。这里面有一部分可能是重复(冗余)的－同样的字符串存在多个不同的实例(a!=b，但a.equals(b))。在实践中，许多字符串由于各种原因造成重复。
起初，JDK提供String.intern()方法处理字符串重复的问题。该方法的缺点是你需要找出哪些字符串需要驻留(interned)。这通常需要一个具备重复字符串查找功能的堆分析工具，比如YourKit profiler。尽管如此，如果使用恰当，字符串驻留会是一个强大的节省内存的工具－它允许你重用整个String对象（每个对象会在底层char[]的基础上增加24字节的额外开销）。
从Java 7 update 6开始，每个String对象都有自己私有的底层char[]。这样允许JVM做自动优化－如果底层的char[]数组从没有暴露给客户端，那么JVM就能去判断两个字符串的内容是否一致，进而将一个字符串底层的char[]替换成另一个字符串的底层char[]数组。
Java 8 update 20中引入的字符串去重特性就是用来做这个的，下面是它的工作原理：

阅读全文

原文： Some REST best practices, 作者：Pierre-Olivier Bourgeois。
译文： 一些REST最佳实践, 译者： yongx

如今，REST APIs 已经非常普遍，几乎所有WEB应用都用到了它们。提供简单，一致，实用的API是种义务，方便其它人很容易的使用。即使下面的这些规范，在你看来很正常，我经常看到人们不遵守它。这是我写这篇文章的原因。
当你设计 RESTful API 时，下面是一些应该牢记的最佳规范。
免责声明：下面的这些规范是根据过去的经验，我认为最好的。如果你有别的想法，咱们邮件讨论。

阅读全文

如果你是一个Java开发者，熟悉 依赖注入 模式, 深度依赖Spring框架的话，在使用Scala做开发时，会问一个问题，在Scala世界里，如何实现类似Spring框架的依赖注入呢？

尽管函数式编程的信徒认为他们不需要DI框架，高阶(high-order)函数足够了。但是对于同时支持面向对象的编程和函数式编程的Scala来说，依赖注入是很好的实现应用的一种设计模式。
蛋糕模式(Cake pattern)是Scala实现依赖注入的方式之一。
蛋糕模式是 Scala 之父 Martin Odersky 在其论文 Scalable Component Abstractions 中首先提到。

什么是蛋糕模式呢? 一个非正式的但是很形象的解释是：

• 蛋糕有很多风味， 你可以根据你的需要增加相应的风味。依赖注入就是增加调料。
• 蛋糕有很多层 (layer)。如果你想要一个更大的蛋糕你就可以增加更多的层。

我们先以Spring常用的User数据库读取的实现为例，看看Scala 风格的依赖注入(蛋糕模式)是如何实现的。

阅读全文

原文： 大型网站系统架构的演化, 作者：李平

一个成熟的大型网站（如淘宝、京东等）的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随业务扩展而完善出来的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。

阅读全文

原文： A Brief History of Scaling LinkedIn

Josh Clemm是LinkedIn的高级工程经理，自2011年加入LinkedIn。他最近(2015/07/20)写了一篇文章，介绍了LinkedIn针对用户规模急速扩大带来的架构方面的变革。
文章有点像子柳写的淘宝技术这十年

2003年是LinkedIn元年，公司成立的目标是连接你的个人人脉以获得更好的的工作机会。上线第一周才有2700个会员注册，时光飞梭，LinkedIn的产品、会员数量、服务器负载都极大的增长了。
今天，LinkedIn全球用户已经超过3.5亿。我们每秒有数十万个页面被访问，移动端流量已占到50%以上 (mobile moment)。所有这些请求都从后台获取数据，而我们的后台系统可以处理每秒上百万次查询。

问题来了： 所有这些是怎么做到的呢？

阅读全文