一般在项目开发中会有很多的统计数据需要进行上报分析，一般在分析过后会在后台展示出来给运营和产品进行分页查看，最常见的一种就是根据日期进行筛选。这种统计数据随着时间的推移数据量会慢慢的变大，达到百万、千万条数据只是时间问题。

在Java程序中，我们想要停止一个线程可以通过interrupt方法进行停止。但是当我们调用interrupt方法之后，它可能并不会立刻就会停止线程，而是通知线程需要停止。线程接收到通知之后会根据自身的情况判断是否需要停止，它可能会立即停止，也有可能会执行一段时间后停止，也可能根本就不停止。

我们可以发现，在最开始有一个判断，如果这个值的范围在[-128,127]之间，那么就从这个缓存（Integer数组）中取，如果不在这个范围那么直接new一个。

equals常见面试题在开始聊之前，我们先看几个常见的面试题，看看你能不能都回答上来。1、equals和==有什么区别？2、hashcode相等的两个对象一定==相等吗？equals相等吗？3、两个对象用equals比较相等，那它们的hashcode相等吗？如果我们不重写equals和hashcode，那么它使用的是Object方法的实现。我们先简单看一下 {代码...

现有一个广告点击数据埋点上报的需求，上报的埋点数据根据点击的广告位置不同做区分进行上报，每个广告位置的数据进行分表存储。（eg：这里大家也不必深究分表存储为什么要这么做，我们只聊策略模式的实际应用）

面试：多线程下Random存在什么样的问题？每个Random实例里面都有一个原子性的种子变量用来记录当前的种子值，当要生成新的随机数时需要根据当前的种子计算新的种子并更新种子变量。当在多线程环境下，多个线程会竞争同一个原子变量的更新操作，由于原子变量的更新时CAS操作，同时只有一个线程会成功，所以会造成大量线程...

在开始文章之前，我这里暂且认为大家已经明白了JVM创建对象分配内存地址的流程，也知道JVM内存划分。基于人道主义我还是放一张图吧，大家对照着看。

上周突然在部署一点很简单的新业务之后，上线没多久突然OOM，大部分接口访问超时，甚至有的直接失败，刚开始以为是查询了什么了大数据导致的，结果看了下CPU，300%。

那么我们在开始介绍Java内存区域之前，我们先放一张内存区域的图，方便我们后面介绍的时候可以对照着看。须知，本文是根据JDK8来介绍的。程序计数器首先它是线程私有的，它也称为代码的行号指示器，字节码解释器就是通过改变程序计数器的位置来确定下一行要执行的代码，它不存在OOM。如果线程正在执行一个Java方法，那么...

之前遇到对List进行遍历删除的时候，出现来一个ConcurrentModificationException 异常，可能好多人都知道list遍历不能直接进行删除操作，但是你可能只是跟我一样知道结果，但是不知道为什么不能删除，或者说这个报错是如何产生的，那么我们今天就来研究一下。

IO流详解一、输入流字节输入流FileInputSteam1、构造方法： {代码...} 2、read方法： {代码...} 3、文件读取：1、read()每次读取一个字节数据，返回字节数，如果到达文件末尾，返回-1。文本 {代码...} {代码...} 执行结果： {代码...} 从执行结果可以看出，前三次读取到了数据，返回了对应的ASCII码，当读取到文件末尾的...

过滤器这东西应该很常见了，但是你的过滤器真的起到拦截的作用了，这里就算你起到拦截的作用了，但是你的过滤器能拦截到指定的路径吗？先看一下我原始写法。

最近在几台测试服务器上跑一些业务数据，但是过了几天服务器突然变的奇慢无比，敲个命令就像卡壳一样，有时候甚至都连接不上，最开始我以为是网络问题，就强行kill掉进程，重新跑一下进程，最后实在受不了，就上阿里云后台说重启下服务器吧，结果看到CPU的占用率已经到达了100%。

先简单说下当出现内存溢出之后，我是如何排查的，首先通过jstack打印出堆栈信息，然后通过分析工具对这些文件进行分析，根据分析结果我们就可以知道大概是由于什么问题引起的。

最近一直忙着处理原来老项目遗留的一些SQL优化问题，由于当初表的设计以及字段设计的问题，随着业务的增长，出现了大量的慢SQL，导致MySQL的CPU资源飙升，基于此，给大家简单分享下这些比较使用的易于学习和使用的经验。

不知道你们有没有对用户输入的东西进行过敏感校验，如果不进行校验，用户属于一些攻击脚本，那么我们的服务就挂逼啦！所以我们首先需要通过过滤器将用户的数据读出来进行安全校验，这里面涉及到一个动作，就是需要将用户的数据在过滤器中读出来，进行校验，通过之后再放行。

前几篇我们介绍了如果通过RabbitMQ发布一个简单的消息，再到工作队列，多个消费者进行消费，最后再到工作队列的分发与消息的应答机制（ACK）；

上篇文章中，我们讲了工作队列轮询的分发模式，该模式无论有多少个消费者，不管每个消费者处理消息的效率，都会将所有消息平均的分发给每一个消费者，也就是说，大家最后各自消费的消息数量都是一样多的。由此也就引发我们今天要介绍的公平分发模式。

上面这种简单的消息队列确实可以处理我们的任务，但是当我们队列中的任务过多，处理每条任务有需要很长的耗时，那么使用一个消费者处理消息显然不不够的，所以我们可以增加消费者，来共享消息队列中的消息，进行任务处理。