关于日志，在大家的印象中都是比较简单的，只须引入了相关依赖包，剩下的事情就是在项目中“尽情”的打印我们需要的信息了。但是往往越简单的东西越容易让我们忽视，从而导致一些不该有的bug发生，作为一名严谨的程序员，怎么能让这种事情发生呢？所以下面我们就来了解一下关于日志的那些正确使用姿势。

老王是某公司的苦逼Java开发，在互联网行业中，业务总是迭代得非常快。体现在代码中的话，就是v1.0的模块是单线程执行的，这时候使用HashMap是一个不错的选择。然而到了v1.5的版本，为了性能考虑，老王觉得把这段代码改成多线程会更有效率，那么说改就改，然后就愉快的发布上线了。

万丈高楼平地起，今天的聊点基础而又经常让人忽视的话题，比如“==”与“equals()”区别？为何当我们重写完"equals()"后也要有必要去重写"hashcode()"呢？ ... 带着这些问题，我们一起来探究一下。

说到分布式缓存，可能大多数人脑海浮现的就是redis了，为什么redis能够在竞争激烈的缓存大战中脱颖而出呢？原因无非有一下几点：性能好，丰富的特性跟数据结构，api操作简单。但是用的人多了，就会出现很多不规范或者疏忽的地方，严重的时候甚至会导致生产事故，所以我们有必要来聊聊在Redis使用过程中的一些“正确姿势“。

关于分布式锁，在互联网行业的使用场景还是比较多的，比如电商的库存扣减，秒杀活动，集群定时任务执行等需要进程互斥的场景。而实现分布式锁的手段也很多，大家比较常见的就是redis跟zookeeper，今天我们主要介绍的是基于zookeeper实现的分布式锁。

最近跟许多朋友聊了下，在这个“跳槽”的黄金季节，大家都有点蠢蠢欲动，所以最近就多聊聊面试的时候需要注意的一些问题，这些问题不一定多深奥，多复杂，但是一不注意的话却容易掉坑。下面看一下面试的时候经常遇到的一段代码:

锁，顾名思义就是锁住一些资源，当只有我们拿到钥匙的时候，才能操作锁住的资源。在我们的Java，数据库，还有一些分布式的环境中，总是充斥着各种各样的锁让人头疼，例如“公平锁”、“自旋锁”、“读写锁”、“分布式锁”等等。

如今不管是在面试还是在我们的工作中，OOM总是不断的出现在我们的视野中，所以我们有必要去了解一下导致OOM的原因以及一些基本的调整方法，大家可以通过下面的事例来了解一下什么样的代码会导致OOM，帮助我们以后在工作中能够通过异常信息来判断是JVM里面哪个区域出现了问题。