概述

我们在日常的生活中，经常会遇到需要对未来的趋势做出一个预测，然后做出当下的决策。

• 比如说我们在运维的时候，我们如果可以预判流量的高低趋势，那么就可以提前做出服务的伸缩决策，如果流量升高后再去扩容，就会导致用户体验的下降，而流量下降后，还维持着很多的服务实例，导致资源浪费；
• 我们在买入一个公司的股票的时候，如果预判它会上涨，我们就会预先买入股票，如果预判它会下跌，那么就会提前卖出；
• 比如一个电力公司如果可以预测将来1-3个月的用电量，根据预判出的用电量的高低，决定煤炭的采购量的多少，合理科学的安排作业生产，使产值可以最大化。

如果你会对如何做预测产生了一些兴趣，通过阅读本文你可以了解到：

1. 预测的理论基础
2. 预测模型ARIMA
3. 使用ARIMA模型的实践

概述

我在2015年的时候，听了关于国内某一家互联网公司的技术分享，他们的技术经历了三个阶段，分别是

1. 传统的LAMP架构
2. 对系统基于业务边界进行垂直切分，包括对数据库进行垂直和水平切割的架构
3. 这个阶段很神秘，没有分享

但是第3阶段，他们提到了Java开发人员不再需要去开发商城端的营销活动类的业务，开发人员的精力全部集中到了中间件、供应链、进销存等重业务软件的开发。因为这种系统架构能够帮组他们提高生产力，在市场竞争中取得优势，所以基于商业的目的考虑，他们没有分享。于是那时在心里留下了一个疑问。最近机缘巧合，公司来了一位资深的产品经理，在和他交流的过程中他多次提到了自动化营销的话题，又一次触发了我对于在2015年心中的那个疑问的思索。 经过一个月左右的调研和思考，有了一些思路和实践，因此阅读完本文，你会知道如下内容

• 如何通过设计系统架构就能够实现将经常变化的业务需求转成规则配置，不再需要开发人员去写代码实现；
• 上述的系统设计带来的一些问题；
• 上述的问题的利和弊的一些思考；

背景介绍

我们在日常的工作中，肯定要收取大量的邮件，你可能会说安装一个邮件客户端不就可以了吗？比如ThundBird，FoxMail等等。你这样说也没有问题，毕竟现在的电脑配置都是超高的，一个基于GUI的邮件客户端并不会消耗你多少资源，用鼠标操作下，也可以查看邮件啊，我想你肯定会遇到电脑死机，不管鼠标怎么点都没响应，然后你不得不去重启电脑，然后不得不去重新打开你重启电脑之前的所有窗口，也许这样的场景不多见，但是只要发生过一次，就要够你难受的，我做过分析，不管是什么操作系统：Windows、Mac、Fedora等，只要是基于GUI的应用，永远是资源消耗大户，所以如果要工作的流畅，就应该避免任何基于GUI的应用，日常工作中，收发邮件是一个频次很高的事件，我们有必要寻找一种邮件客户端工具，对系统资源开销最少，操作方面最高效的，所谓磨刀不误砍柴工，如果你想提高日常的办公效率，本文下面将会给你介绍一款基于命令行邮件客户端软件：Mutt，阅读完本文你会学会如下内容：

1. 如何在 Fedora下安装 Mutt和相关的依赖；
2. 如何配置 Mutt以及利用mutt发送和接收邮件；

全文阅读完大概需要5至8分钟。

概述

在之前的一篇文章，解决JVM内存泄漏的问题中，涉及到了GC的问题，为了把GC切底弄清楚，花了不到2个星期的业余时间，把这一块的知识复习了一下，所以现在开始对GC中的CMS算法做下总结，原来计划是上个周周末写这篇文章的，但是因为有其他事情，总是不断打断这个计划，于是一直拖到了8月份的下旬了。

JVM的垃圾回收算法有很类别，比如：并行垃圾回收、stop-the-world、并发垃圾回收，垃圾回收器可以是这个类别中的的一种或者多种的组合，因为我经常使用的是CMS垃圾回收器，因此我这里详细介绍CSM垃圾回收算法。阅读完本文你会了解如下的内容：

1. 什么是CMS，它是为了解决什么问题而出现的？
2. CMS是如何工作的？
3. CMS使用过程中会经常遇到什么问题，我们需要如何避免这种问题？

概述

最近在项目中碰到了Jar包冲突的问题，比如一个组件A依赖了组件B的1.0版本，组件C依赖了组件B的2.0版本，我们如果是使用Maven进行依赖管理的时候，Maven会根据一些策略来舍弃掉组件B的某一个版本。下面我总结了Maven的一些依赖冲突的时的处理策略。 

 最短路径原则

比如上面提到的场景，组件A和组件C对组件B的路径分别为：

A(1.0) ---> X(1.0) ---> B(1.0) 
C(1.0) ---> B (2.0) 

那么Maven会计算出哪个是最短的依赖路径，就会优先加载，这个例子中，会加载组件B的2.0版本。

最先声明原则

如果组件B的1.0和2.0版本依赖的路径相同，此时怎么办？比如下面的依赖路径：

A (1.0) ---> B (1.0)  
C (1.0) ---> B (2.0) 

 在这个场景中，Maven会分析出哪个组件是最先被声明的，比如下面的声明方式：

概述

根据上一篇文章，将JVM升级到212版本，并追加设置了-Xmx和-Xms参数之后，生产环境的JVM内存一直维持在300-800M之间，高负载和低负载的实例，内存开销都在这个范围之内。所以从这两天的线上验证的现象来看是符合预期的，证实了之前的猜测是正确的（之前的结论参考：JVM的内存泄漏调查）。

详细分析

下面我将结合听云监控上的数据进行分析和论证。

下图是内存开销，可以看出内存开销在500M范围以下。

下面是Eden区域的内存开销，可以看出eden区大小在250M之内。

概述

        最近这半个月生产环境的服务出现了一个比较奇怪的现象，相同的一个服务，有两个实例，其中一个实例的负载比较高，RPM有500-1000左右，另一个实例的RPM在20-50之间，其中低负载的实例吃的内存比较多，能吃到8G左右的内存，另一个高负载的实例，内存稳定维持在2-3个G，吃内存比较高的那个服务，运维在日常巡检的时候发现会手动重启一次服务，避免服务出现OOM的问题。因为这个问题比较频繁，所以反馈到研发这边。这个问题的经过分析定位，排除日志堆积的问题、排除是听云探针的问题之后，把原因定位在了JVM内存自动增长导致的问题，因为根据监控平台上可以看到GC的回收频次很低，因为一旦JVM可用的内存不够，如果没有设置最大可用内存，那么JVM就会自动增长，而自动增长内存后，就不会达到GC触发的条件，这样就导致内存一直增长，而没有垃圾回收的问题。

详细的分析过程

         首先让运维通过利用jmap的方式将JVM的内存信息dump出来，

jmap -dump:format=b,file=文件名.dump 进程id 

经过分析发现了听云的对象占用了大概20%左右的内存空间：

概述

          在最近的一个maven多模块项目中，B module依赖了A module中的一个类，用如下命令打包的时候

mvn clean install

遇到错误：

maven cannot find symbol class Person

经过一番的调查，发现是由于在父工程的POM文件缺少pluginManagement节点引起的问题。下面是问题的具体分析过程。

详细介绍

在碰到这个问题的时候，第一直觉是和maven的module机制有关系，因为工程可以在idea里正常启动。 判断应该是自己对于maven模块机制的一些知识欠缺，于是在maven官网上学习了一下关于多模块工程的知识，其中有如下的收获：

概述

         在使用Hibernate级连设置的时候，我们可以设置CascadeType.ALL, 这样如果删除了父对象，就会导致相关的子对象也会被删除。而如果子对象是可以独立存在，那么就不能被删除，本文主要介绍设置了CascadeType.ALL之后，父子对象被级连删除的详细情况和应该如何设置级连属性。

详细介绍

         假设我们有一个Student实体和一个Course实体，一个学生会选修多个课程，一个课程可能会被多个学生选择，所以我们这里就可以有如下的实体定义：

概述

本文将介绍如何高效的使用Hibernate的ManyToMany。

具体说明

假设我们有Student实体和Course实体，一个学生可以修多个课程，一个课程会有多个学生来学习。因此我们有如下的实体定义：