背景介绍

我们在日常的工作中，肯定要收取大量的邮件，你可能会说安装一个邮件客户端不就可以了吗？比如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实体，一个学生可以修多个课程，一个课程会有多个学生来学习。因此我们有如下的实体定义：

概述

        我们在实际的项目中，可能会将一些SQL的关键字作为实体的属性名，我们可能会使用如下的数据库：MySQL 、PostgreSQL 、SqlServer，每个数据库都有各自不同的保留关键字，因此如果我们要将这些关键字作为实体属性的名称，或者数据库的表名，数据库就会报错。如何解决这个问题？我们可以用如下的两个方法。

在实体定义的时候通过 标注的方式指定

我们如果有如下的实体定义

概述

        我们在使用ORM工具时，直接和实体进行交互，就可以操作数据库，不再需要写 SQL语句。但是Hibernate不是软件饮弹，我们还是需要关注它生成出来SQL。那么在一次操作的过程中实体会经历哪些状态？各个状态又有哪些含义和作用？

详细解释

Transient

         一个对象刚创建时的状态，这个状态下的对象还没有映射为数据库中的记录。只有调用Session.save()或者 EntityManager.persist()方法的时候，状态会切换为Managed。

Managed

          刚创建的对象通过调用Session.save()或者EntityManager.persist()方法的时候，就会从 Transient状态切换到Managed状态，该状态下的对象的任何属性值改变都会在Session.flush()的时候，自动同步到数据库中，因此我们不需要手动执行insert/update/delete这些方法。