自Oracle JDK 7 update 4之后，JVM中引入了一种新的垃圾收集器--G1垃圾收集器(Garbage-First Collector)。之前的一篇文章，有介绍一些基本的垃圾收集器，比如比较常用的CMS垃圾收集器，但即便是CMS垃圾收集器，其也有一些不足，比如，不能很好地处理内存碎片的问题，随着应用的运行，也会导致内存使用率不高，因此通常在使用CMS垃圾收集器时，会设置相对较大的堆大小。G1垃圾收集器则旨在能够比CMS垃圾收集器更合理地管理内存，或者说更智能地管理内存。本文将介绍有关G1垃圾收集器的基本原理，以便开发人员能考虑在生产中使用之。
随着业务的发展，应用系统中的配置通常会越来越多，常见的一些应用配置大致会有数据源配置，数据源组件配置，业务组件配置等，对于这类配置都会比较稳定且较少变化，通常会放在文件中随应用一起发布。但实际中会有某些配置信息变化有一定频率和规律，并且希望能够做到尽量实时，比如一些营销类，或活动类应用系统，若使用传统的配置文件，加上重新发布应用可能会有些不方便，因此，才有了分布式配置管理平台，旨在能更好地解决这类问题。本文将介绍相关细节，及一个轻量的开源实现diablo。
InnoDB把数据保存在表空间内，本质上是一个由一个或多个磁盘文件组成的虚拟文件系统。InnoDB用表空间并不只是存储表和索引，还保存了回滚段、双写缓冲区等。本文将介绍InnoDB表空间的相关性质。
对于DBA，通常需要对数据库服务器的磁盘I/O作相关监控管理，以免发生I/O资源过于紧张，进而导致服务器不稳定及崩溃。除此之外，磁盘空间管理也很重要，需要为数据库保证足够的磁盘空间。ACID设计模型为了保证数据的可靠性(比如，通过写Undo Log等)，也需要I/O资源。而InnoDB在运行过程中，会尽可能降低I/O操作和优化磁盘文件的组织(如，延迟某些I/O操作直到数据库空闲时，或者为了保证数据一致性，在数据库重启后执行某些恢复操作)。本文将描述InnoDB的磁盘I/O和文件管理的相关细节。
对于业务发展前期，可能我们会比较关注单个请求的耗时，频次等基本指标，以针对作出相应调整或优化。但随着系统业务发展，整个系统的调用链将变得愈发复杂，一个前端请求可能最终需要调用很多次后端服务才能完成，当整个请求变慢或不可用时，我们是无法得知该请求是由某个或某些后端服务引起的，这时就需要解决如何快读定位服务故障点，以对症下药。于是就有了分布式系统调用跟踪的诞生。本文将阐述与分布式系统调用跟踪相关的一些实践经验。
对于开发人员而言，对于锁和事务不会陌生。为了避免多线程同时读写共享数据发生竞争的问题，因此，锁是一种比较常用的方式。而事务的定义，主要体现在其基本特性：原子性，一致性，隔离性，持久性。之前的一篇文章有所提到过。但我相信很多开发人员对事务和锁的理解是不够深入的，包括我自己，始终觉得好像很容易回答，又答不出所以然，平常也应该有人问某条SQL会加什么锁呢，为什么我在方法上加了@Transactional就发生死锁了呢？本文将阐述InnoDB存储引擎中的锁及事务模型相关的细节，希望能帮助开发人员了解InnoDB如何有效处理并发事务等机制。
对于一个站点，大家应该都比较清楚，资源大概就分为静态资源(js/css等)，图片，文件，动态数据等。对于加快动态数据访问，通常是需要后端程序或数据结构作优化，才能比较明显地得到提升，并不是一个立竿见影的过程。但对于静态资源(js/css等)，图片，文件等的访问，则可以通过一些缓存，压缩，合并等技术，就能得到比较明显的提升，本文将探讨下使用缓存来加快静态资源，图片等的访问，主要使用Varnish。
随着业务不断扩大，系统产生的各种日志也已经趋于暴涨，要想从这些庞大的日志中检索出自己想要的信息，特别是一些错误信息，是至关重要的。对于一个比较成熟的日志平台，需要解决几个问题：如何规范日志，如何收集日志，如何传输日志，如何存储日志，如何分析展示日志等等，恰逢最近需要为业务团队提供日志服务，旨在能及时发现并解决线上出现的异常问题，主要是从ELK Stack出发进行日志平台构建，本文将阐述其中的一些细节和思路。
最近，需要为业务团队提供图片及文件存储服务，早前，接触过的一些存储方案大概有：利用Linux系统级别的NFS文件服务，即在NFS Server和NFS Client之间进行文件同步，但NFS不太容易实现集群，从而避免单点问题，而且维护起来也比较麻烦，需要同步在接收上传的机器上建立NFS Client；也有利用Nginx+Lua+ImageMagick的方案，但在文件备份等需要借助一些其他手段才能达到。当然也有一些专门的分布式文件系统，如HDFS，GlusterFS等，但主要是针对大文件存储。最近接触到一个轻量的分布式文件系统--FastDFS，是由国人开发，比较遗憾的是关于FastDFS的文档都比较零散，在这个站点上要稍微集中一些。本文将对FastDFS进行一番探究实践。
不出意料，java.lang.OutOfMemoryError可以算是Java应用中最常见的JVM错误了，这类错误往往是Java堆没有足够的空间容纳新对象，但引起这类错误的原因还有诸多种，可能平时很少有缘分能相见，本文将探究其中几种引起该错误的场景，以备不时之需。
随着Java应用地运行，可能会出现一系列性能问题，如系统吞吐量低，系统延迟高等，这些通常会直接影响用户体验，造成用户流失，严重时，系统将会崩溃，为了避免这样的情况发生在线上，通常会在上线系统前作一些指标测试，如吞吐量，延迟等，当然影响这些指标的因素可能会有很多，如计算复杂度，网络问题，但本文将仅从JVM的垃圾收集调优讲起。
日常开发中，大多数程序员并不会直接接触AbstractQueuedSynchronizer(AQS)类，但其在并发工具中缺无处不在，并作为内部的标准同步器，如ReentrantLock，Semaphore，Java线程池中的Worker等。本文将介绍AQS相关的实现细节。
在日常开发中，除了编写程序外，其他比较关注的会有垃圾收集器(GC)相关的问题，在默认的JVM行为下，可能会随着业务量或应用需求，这样的默认行为可能无法满足需求(主要可从吞吐量或系统暂停响应等因素考虑)，对垃圾收集器(GC)的调整，是比较普遍的，当然也可能会针对使用不同的垃圾收集器(GC)时，进一步调整一些JVM参数，如堆大小，分代配额等信息，而能帮助开发人员在调整这些参数前，作一些跟踪判断的重要信息，则是垃圾收集日志。本文将详述相关的一些GC日志细节。
服务器利用线程技术响应客户请求已经很常见，这的确提高了服务器的响应处理能力，但通常服务器端并不会为每个客户端请求分配一个新的线程对象，在大量的客户端的请求下，这种处理方式将会创建大量的线程来处理请求，这对内存和CPU都是很不利的，于是需要一种更合理的线程技术，这就是线程池技术。在日常开发中，也或多或少会接触到线程池，比较Servlet容器处理浏览器请求的线程池，数据库连接池等，本文将理解一番JDK本身的线程池(ThreadPool)实现，与其他线程池相比，也会大同小异。
众所周之，Java最强大的地方之一就是其自动内存管理机制，也就不需要像C/C++语言那样，需要开发人员手动进行内存管理，需要时刻关注内存应该何时正确地被释放。自动内存管理机制将程序员从内存管理的凶险解脱出来，这将大大提升Java开发人员的生产力，但作为Java开发人员，即使不用直接面对内存管理，但却应该对JVM的内存管理机制有所掌握，对自己的编程能力也会有潜移默化的提升。本文将对JVM内存管理进行一番解读，实现主要是HotSpot Virtual Machine(J2SE 1.5)。
在日常中，经常会碰到一些环境相关的术语，也有说是上下文的，Maven中通过profile抽象出了环境配置，使开发人员可以通过不同的profile来定义不同的build上下文，Spring中也有环境一说，通过接口Enviroment来抽象，其随着Spring IoC容器的初始化而建立起来，本文将探究一番Spring运行时环境的相关细节。
在Spring容器中，有一个基础的抽象概念：资源(Resource)，其主要是对文件或类路径等资源的抽象，当对Spring容器进行初始化等操作时，会将配置文件以Resource参数对象传入给Spring容器，内部再通过ResourceLoader加载该资源，本文将比较探讨下Spring对资源的处理细节。
IoC(Inversion of Control)，即控制反转， 也可简单说为依赖注入(DI)，旨在将对象间的依赖关系交由 外部环境去处理， 而不是由对象自己去获取，这将大大提升开发效率和降低程序复杂度，在Spring中，这个外部环境就是Spring IoC容器， 也是Spring生态的核心基础，除了Spring的IoC实现外， 其他还有诸如Guice这样的IoC实现， 本文将对Spring的IoC实现进行探讨一番。
Spring Web 3.1之后引入了叫作Flash Attribute的功能，旨在解决类似POST/Redirect/GET这种请求模式中的属性传递问题，但由于从老系统到新系统的迁移过程中，用户Session都开始使用基于Redis的会话组件(HttpSession的Redis版本)，在老系统的POST/Redirect/GET这种请求模式下出现了问题，因此记下一笔。
Java Memory Model(Java内存模型，简称JMM)，作为Java语言规范的一部分(主要在JLS的第17章节介绍)，其定义了多线程之间如何通过内存进行交互，在旧的JMM中，存在一些不够明确和过于限制的问题，比如对final，volatile等关键字的语义约束问题，例如，有可能出现final字段的值会发生变化，或者阻止编译器的优化操作，还有比较熟知的double-checked问题，于是在新的JMM中，针对这一系列问题作出了修订，最终在JSR133中进行了详细描述，本文将对Java内存模型作一番理解。
在日常开发中，经常会涉及到数据库读写访问，对数据库访问通常会通过数据库连接池来获取数据库连接，再进行SQL，最近涉及到迁移数据，在日志中偶尔出现一些MySQL数据库连接错误，通过DB配置和连接池配置最终解决。
相信每个人都做过系统重构相关的事儿，简单说就是对系统不合理的地方进行修复， 比如系统架构，数据库设计，代码规范，或某一行代码等，重构需要更多的思考， 而不是一畏地写代码，但又不能考虑太多，做到有的放矢。最近对老系统进行重构， 与其说重构，不如说重写，因为涉及到的有 系统架构， 数据库设计， 代码规范等， 由于旧代码已经烂不忍睹，因此有了这么一次系统地重构， 正常的重构应该是每天的事儿，而不是某天的事儿。 本文将尽量详细讲述重构中自己主要涉及的部分，但愿对你有所帮助。
在日常开发中，一旦涉及到多个表操作时，便需要考虑事务及数据一致性的问题， 通常就是事务原子性和 保证数据能被正确且完整地记录， 本文将探讨下遇到的系统结算中碰到的相关问题。
如今，哈希已经被广泛应用在各种系统及应用中， 而一致性哈希则是其中一种常用的服务均衡算法， 旨在P2P环境中，如何在动态的网络中分布和路由节点，
在并发问题中， 还有一个比较关键的问题就是指令重排序 (在不改变程序语义的前提下，CPU为了更高效地利用缓存或寄存器)， 但这同时会带来一些并发问题，造成一些数据不完整，不一致等问题， 因此JMM(Java Memory Model)就规范了一些Happen-Before的偏序关系， 以避免这些并发问题。
生产中，我们需要Nginx访问日志，查一些需要的数据，这里作一些收集。
并发问题，总是一个比较值得探究和有趣的话题， 有时候并发问题看起来会很简单，有时又让人迷惑，不出问题则已，一出问题则难揪诱因， 只能靠个人小心为慎，来尽量降低这种威胁，并发中， 锁则起到了至关重要的作用， 用得好谢天谢地，用得不好只能等待问题出现，所以觉得，还是有必要对锁进行一番整理记忆， 可能其中，我也会头脑发晕，感谢邮件指出。
在现实生活中，大多数面向用户的系统，都应该提供一些基本的查询搜索功能， 这将更好帮助用户找到自己想要的数据，不论从性能还是查询能力， 都会比DB更强大，从而也是减轻DB压力的一种途径， 本文将对ES进行一些初探。
当Zookeeper集群在生产中变得愈发庞大时，如何能更好的管理和维护这些服务器，将是本文所要探讨的。
当应用中使用了Zookeeper作为我们的分布式协调工具时， 此时就需要对其进行各种管理，监控等等运维工作， 本文将主要介绍Zookeeper的内部组件， Zookeeper内部如何工作，使用的协议， 以及当提供高性能服务时的容错机制等。
Curator是基于Zookeeper Client的一套高级API集， 其主要目的是隐藏Zookeeper复杂的连接管理细节，其实现了一些基本的工具，如锁， 缓存等，像 create， delete， getData等操作，允许我们链式调用， 被称为fluent，同时也提供了如 命名空间， 自动重连等功能。本文将使用 Curator来实现之前的Master。
本文将关注Zookeeper中一些比较棘手的方面，主要与会话和时序相关。 虽然不影响我们开发，但当遇到这些问题时，能够有更好的理解。
在生产中使用Zookeeper，我们难免会遇到无法预料的故障，通过本文将了解到Zookeeper的的几种故障问题，及其如何处理这些故障。
本文将讲述如何使用Zookeeper Client API进行编程， 以在分布式应用中实现协调功能， Zookeeper支持Java和C的API，本文主要使用Java语言。
前两天被问到有关Zookeeper的一些问题，但确没有很好的回答上来。 之前也接触过Zookeeper，比如使用其Watcher实现一些通知， 或者Leader选举功能，也可以作为如Dubbo服务框架的注册中心等， 但是对Zookeeper的运作原理等是不太了解的，也没有认真仔细研究过， 特此希望通过阅读和记录文章，深入理解一番Zookeeper，觉得其中很多分布式的思想，会对自己有很大的帮助。
Mybatis通过内部的Transaction和TransactionFactory来管理事务。 本文将探究一番Mybatis事务管理的一些细节。
Mybatis初始化是一个比较繁琐的过程，通过将配置的XML文件映射为其内部的Configuration对象， 由其统一管理。本文将通过源码跟踪其初始化配置的整个过程，以进一步了解Mybatis内部工作原理。
我相信每一个工程师都会有自己心中的架构之路，无论你从事过什么样的产品项目开发，系统总是会有自己的架构， 在产品生命周期过程中，架构也是会随之慢慢演进，改善的，而不可能一步到位，特此用一篇文章来记录自己所感， 可能有些凌乱，但会慢慢改进。
本文将讲述如何使用NGINX缓存。NGINX缓存可以将后端服务器的响应保存在磁盘上，当客户端发来请求时， 会直接使用缓存来响应客户端，而不会去请求后端服务器。
通常, Nginx作为Web服务器, 需要配置一系列虚拟服务器来负责处理特定的域名或者IP。 每个虚拟服务器需要定义处理特定URL集的Location实例, 每个Location实例则可以 代理请求, 返回文件, 重写URL(将请求重定向到其他虚拟服务器), 或者返回错误码, 并且你也可以定义错误码对应的页面。
昨日, 一老友突然发个信息问在没, 有事, 当时一紧张, 想到底应该说在还是不在呢?接着又来了几句说会不会PS, 还好这位朋友没有问我会不会修电脑, 心理顿时欣慰了。 就勉强问要P啥(心理完全没底, 几年没安装过PS了, 就大学学了几个皮毛), 沟通后, 知道是要修改图片上的文字, 感觉还好, 瞎搞瞎搞就能弄出来了。
一直对JS的继承概念有点模糊, 大体知道是怎么回事, 但也没有去深究过, 今天翻阅【JavaScript语言精髓】一书的第五章比较深刻进行认知, 特此记录一番。
除了QQ, 当前最火爆的社交工具无非是微信, 或许连QQ都难以匹敌, 更重要的是其更是一个平台, 一个可持续扩展的平台, 无论是公众号, 微店, 支付等, 都使得微信被运用得更为广, 再而深。 之前做了一个关于公众号对接的, 实现用户只需第一次登录即可永久自动登录的功能, 觉得是个比较实用的功能, 分享如下:
当后端Web服务器为了支撑更大的吞吐量, 减少请求延迟时, 就需要部署多个Web服务器同时提供服务, 这个时候我们也需要用到Web代理的负载均衡了.
最近做一个企业团购相关的项目, 这两天有人也提出了有关业务规则的一些东西, 特别一些有关营销的业务, 比如送积分, 送券这些。假如我们要搞一些营销活动, 对一次性购买多少件或多少钱的用户送上一张面值不同的券, 放在平时, 可能马上就开个feature, 在下单后判断用户所支付的钱是否满足这个条件, 满足则送, 不满足就不送。 但是, 要是现在希望更吸引用户, 我要降低门槛, 或增大面值, 难道又开个Hotfix改这段逻辑?似乎不是没有道理, 但是, 世间变化的东西太多, 我们人太难预料和 把控, 那么如何去更好地认识这种问题呢?
在开发中, 单元测试是必不可少的, 个人觉得越是庞大复杂的系统, 就越应该具有良好的测试覆盖, 也许一开始会觉得很费时和多余, 但这无疑是能把问题暴露在上线之前的有利保障。按照一般的系统架构, 通常会将系统垂直分为Dao, Service, Controller三层, 所以我们需要单独对这几层进行。