从平均情况来看，应用程序中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中引入的字符串去重特性就是用来做这个的，下面是它的工作原理：
一些 REST 最佳实践
原文： Some REST best practices, 作者：Pierre-Olivier Bourgeois。
译文： 一些REST最佳实践, 译者： yongx
如今，REST APIs 已经非常普遍，几乎所有WEB应用都用到了它们。提供简单，一致，实用的API是种义务，方便其它人很容易的使用。即使下面的这些规范，在你看来很正常，我经常看到人们不遵守它。这是我写这篇文章的原因。
当你设计 RESTful API 时，下面是一些应该牢记的最佳规范。
免责声明：下面的这些规范是根据过去的经验，我认为最好的。如果你有别的想法，咱们邮件讨论。
Scala编程的蛋糕模式和依赖注入
如果你是一个Java开发者，熟悉 依赖注入 模式, 深度依赖Spring框架的话，在使用Scala做开发时，会问一个问题，在Scala世界里，如何实现类似Spring框架的依赖注入呢？
尽管函数式编程的信徒认为他们不需要DI框架，高阶(high-order)函数足够了。但是对于同时支持面向对象的编程和函数式编程的Scala来说，依赖注入是很好的实现应用的一种设计模式。
蛋糕模式(Cake pattern)是Scala实现依赖注入的方式之一。
蛋糕模式是 Scala 之父 Martin Odersky 在其论文 Scalable Component Abstractions 中首先提到。
什么是蛋糕模式呢? 一个非正式的但是很形象的解释是：
- 蛋糕有很多风味， 你可以根据你的需要增加相应的风味。依赖注入就是增加调料。
- 蛋糕有很多层 (layer)。如果你想要一个更大的蛋糕你就可以增加更多的层。
我们先以Spring常用的User数据库读取的实现为例，看看Scala 风格的依赖注入(蛋糕模式)是如何实现的。
大型网站系统架构的演化
原文： 大型网站系统架构的演化, 作者：李平
一个成熟的大型网站（如淘宝、京东等）的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随业务扩展而完善出来的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。
LinkedIn架构这十年
原文： 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)。所有这些请求都从后台获取数据，而我们的后台系统可以处理每秒上百万次查询。
问题来了： 所有这些是怎么做到的呢？
使用cgroups限制MongoDB的内存使用
cgroups，其名称源自控制组群（control groups）的简写，是Linux内核的一个功能，用来限制，控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等）。
这个项目最早是由Google的工程师在2006年发起（主要是Paul Menage和Rohit Seth），最早的名称为进程容器（process containers）。在2007年时，因为在Linux内核中，容器（container）这个名词有许多不同的意义，为避免混乱，被重命名为cgroup，并且被合并到2.6.24版的内核中去。自那以后，又添加了很多功能。
使用 cgroup，系统管理员可更具体地控制对系统资源的分配、优先顺序、拒绝、管理和监控。可更好地根据任务和用户分配硬件资源，提高总体效率。
在实践中，系统管理员一般会利用cgroup做下面这些事：
- 隔离一个进程组（比如：nginx的所有进程），并限制他们所消费的资源，比如绑定CPU的核。
- 为这组进程 分配其足够使用的内存
- 为这组进程分配相应的网络带宽和磁盘存储限制
- 限制访问某些设备（通过设置设备的白名单）
基于dubbo框架下的RPC通讯协议性能测试
原文: 基于dubbo框架下的RPC通讯协议性能测试,作者: lengfo
Dubbo RPC服务框架支持丰富的传输协议、序列化方式等通讯相关的配置和扩展。dubbo执行一次RPC请求的过程大致如下：消费者（Consumer）向注册中心（Registry）执行RPC请求，注册中心分配服务URL并路由到具体服务提供方（Provider），消费者和服务提供方建立网络连接，服务提供方在本地创建连接池对象并提供远程服务，对于长连接类型协议（如dubbo协议）将保持连接，减少握手认证，调用过程中可以避免频繁建立和断开连接导致的性能开销，保持长连接需要有心跳包的发送，所以对于非频繁调用的服务保持连接同样会有消耗。更多关于dubbo详细介绍请参照官方文档（http://alibaba.github.io/dubbo-doc-static/Home-zh.htm）。
1、支持常见的传输协议：RMI、Dubbo、Hessain、WebService、Http等，其中Dubbo和RMI协议基于TCP实现，Hessian和WebService基于HTTP实现。
2、传输框架：Netty、Mina、以及基于servlet等方式。
3、序列化方式：Hessian2、dubbo、JSON（fastjson 实现）、JAVA、SOAP 等。
本文主要基于dubbo框架下的通讯协议进行性能测试对比。
架构学习资料整理（2013）
地瓜哥2013攒的架构资料：分享D瓜哥最近攒的资料（架构方面）
以前见过零零散散地介绍一些知名网站架构的分析文章。最近D瓜哥也想研究一下各大知名网站的架构。所以，就搜集了一下这方面资料。限于时间问题，这篇文章分享的文章并没有都看完，所以不保证所有文章的质量。另外，如果有朋友发现更好的文章，欢迎留言告知。再补充进来。
RPC框架的性能比较
永源科技做的一个RPC框架的性能测试。
原文： RPC框架性能基本比较测试
gRPC是Google最近公布的开源软件，基于最新的HTTP2.0协议，并支持常见的编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议升级版本，目前各大浏览器都在快马加鞭的加以支持。 我们可以设想一下，未来浏览器支持HTTP2.0，并通过现有开源序列化库比如protobuf等，可以直接和各种语言的服务进行高效交互，这将是多么“美好”的场景！
gPRC的Java实现底层网络库是Netty，而且是用到最新的Netty5.0.0.Alpha3的开发版本，因为最新版本针对HTTP/2做了很多改进。 为了跨语言，gPRC也和其他方案一样，采用了类似古老IDL的接口描述语言，利用自家的Protobuf项目带的protoc编译器来生成框架代码。这和目前最流行的Facebook开源的，现为Apache顶级项目的Thrift原理一致。
我比较好奇，这个新出世的框架的性能怎么样，和现有的RPC开源方案比较如何。就花了一些时间进行简单比较。 我选择了以下五种开源项目进行测试：gRPC, Thrift, Wildfly, Dubbo, JBoss EAP。 为了简化，测试范例都使用项目自带的demo或者sample等进行简单修改，使得跨进程网络调用次数一致。
Scala 2.12 拥抱 Java 8
在今年(2015)的旧金山的ScalaDays会议上，来自Scala核心团队的Lukas Rytz分享了一个演讲：The JVM Backend and Optimizer in Scala 2.12的技术细节，主要基于Java 8平台上一些改变， 比如Lambda, 缺省方法等。第二部分主要介绍了生成的字节码的优化。
本文是对第一部分做的笔记。
因为2.12还没有正式发布，一下特性可能还无法校验。
