问题背景及要求

• 需要对评论进行点赞次数和被评论次数进行统计，或者更多维度
• 要求高并发、高性能计数，允许极端情况丢失一些统计次数，例如宕机
• 评论很多，不能为每一个评论都一直保留其计数器，计数器需要有回收机制

背景

上午刚到公司，准备开始一天的摸鱼之旅时突然收到了一封监控中心的邮件。

心中暗道不好，因为监控系统从来不会告诉我应用完美无 bug，其实系统挺猥琐。

打开邮件一看，果然告知我有一个应用的线程池队列达到阈值触发了报警。

由于这个应用出问题非常影响用户体验；于是立马让运维保留现场 dump 线程和内存同时重启应用，还好重启之后恢复正常。于是开始着手排查问题。

前言

最近有些朋友在面试阿里，加上 Java-Interview 项目的原因也有小伙伴和我讨论，近期也在负责部门的招牌，这让我想起年初那段长达三个月的奇葩面试经历?。

本来没想拿出来说的，毕竟最后也没成。但由于那几个月的经历让我了解到了大厂的工作方式、对候选同学的考察重点以及面试官的套路等都有了全新的认识。

当然最重要的是这段时间的查漏补缺也让自己精进不少。

阅读全文

作者:aCoder2013 首发博客地址:https://github.com/aCoder2013/blog/issues/3

前言

今天小伙伴遇到个小问题，线程池提交的任务如果没有catch异常，那么会抛到哪里去，之前倒是没研究过，本着实事求是的原则，看了一下代码。

阅读全文

几天前，我偶然地将之前写的用来测试AtomicInteger和synchronized的自增性能的代码跑了一下，意外地发现AtomicInteger的性能比synchronized更好了，经过一番原因查找，有了如下发现：

在jdk1.7中，AtomicInteger的getAndIncrement是这样的：

阅读全文

原文链接  作者：Adrianos Dadis　译者：买蓉（sky.mairong@gmail.com）　校对：方腾飞

在高负载多线程应用中性能是非常重要的。为了达到更好的性能，开发者必须意识到并发的重要性。当我们需要使用并发时， 常常有一个资源必须被两个或多个线程共享。

在这种情况下，就存在一个竞争条件，也就是其中一个线程可以得到锁（锁与特定资源绑定），其他想要得到锁的线程会被阻塞。这个同步机制的实现是有代价的，为了向你提供一个好用的同步模型，JVM和操作系统都要消耗资源。有三个最重要的因素使并发的实现会消耗大量资源，它们是：

• 上下文切换
• 内存同步
• 阻塞

阅读全文

一个因中断或者超时的调用可能会引起数据丢失和CPU爆满。

前几天读LinkedTransferQueue（以下简称ltq)的源码，想加深下对松弛型双重队列的理解，无意中发现了这个问题:），经过仔细检查后确认了这是个bug，存在于JDK1.7.0_40和刚发布的JDK8中，去google和oracle官方似乎也没有搜索到这个问题。

重现bug：先来重现下这个bug，由于对并发线程的执行顺序预先不能做任何假设，所以很可能根本就不存在所谓的重现错误的“测试用例”，或者说这个测试用例应该是某种“执行顺序”。所以我一开始的做法是copy了一份ltq的源码，通过某个地方加自旋…但是这种方法毕竟要修改源码，后来我发现直接debug进源码就可以轻易重现bug了。 阅读全文

问题描述

在C/S模式中，有时我们会长时间保持一个连接，以避免频繁地建立连接，但同时，一般会有一个超时时间，在这个时间内没发起任何请求的连接会被断开，以减少负载，节约资源。并且该机制一般都是在服务端实现，因为client强制关闭或意外断开连接，server端在此刻是感知不到的，如果放到client端实现，在上述情况下，该超时机制就失效了。本来这问题很普通，不太值得一提，但最近在项目中看到了该机制的一种糟糕的实现，故在此深入分析一下。 阅读全文

感谢trytocatch投递本文。

前言

阅读本文前，需要读者对happens-before比较熟悉，了解非阻塞同步的一些基本概念。本文主要为happens-before法则的灵活运用，和一些解决问题的小技巧，分析问题的方式。

背景介绍

原始需求为：本人当时在编写一个正则替换工具，里面会动态地显示所有的匹配结果（包括替换预览），文本、正则表达式、参数，这些数据的其中一项发生了变化，结果就应该被更新，为了提供友好的交互体验，数据变化时，应该是发起一个异步请求，由另一个独立的线程来完成运算，完成后通知UI更新结果。由于是动态显示，所以提交会非常频繁。 阅读全文

感谢网友trytocatch的投稿

前言

相比上一 篇而言，本文不需要太多的准备知识，但技巧性更强一些。因为分析、设计的过程比较复杂繁琐，也限于篇幅，所以，主要展示如何解决这些需求，和讲解代码。另外，所讲的内容也是后一篇实战中需要用到的一个工具类。

需求介绍

我需要编写一个同步工具，它需要提供这样几个方法：await、pass、cancel。某个线程调用await时，会被阻塞；当调用pass方法时，之前因为await而阻塞的线程将全部被解除阻塞，之后调用await的线程继续被阻塞，直到下一次调用pass。

该工具同时还维护一个版本号，await方法可以带一个目标版本号，如果当前的版本号比目标版本号新或相同，则直接通过，否则，阻塞本线程，直到到达或超过目标版本。调用pass的时候，更新版本号。

如果停止了版本更新，可使用cancel方法来解除所有因await而阻塞的线程，包括指定版本号的。此方法用于避免无谓地等待。若await发生在cancel之后，则仍将被阻塞。

因为CountDownLatch不允许重复使用，CyclicBarrier只支持固定个数的线程，并且都没有维护一个版本号，所以没有已有的类能实现上面的需求，需要自己实现。 阅读全文

感谢trytocache投递本文。

前言

本文写给对ConcurrentLinkedQueue的实现和非阻塞同步算法的实现原理有一定了解，但缺少实践经验的朋友，文中包括了实战中的尝试、所走的弯路，经验和教训。

背景介绍

上个月，我被安排独自负责一个聊天系统的服务端，因为一些原因，我没使用现成的开源框架，网络那块直接使用AIO，收数据时，因为只会从channel里过来，所以不需要考虑同步问题；但是发送数据时，因为有聊天消息的转发，所以必需处理这个同步问题。AIO中，是处理完一个注册的操作后，再执行我们定义的方法，此时，如果还有数据需要写，则继续注册写操作，如果没有则不注册；提交数据时，如果当前没有注册写操作，则注册一个，否则仅提交（此时再注册则会报异常）。这样，需要同步的点就是：如何知道当前还有没有数据需要发送（因为其它线程也可以提交数据到此处），和如何知道此次提交时，有没有注册写操作。总之，要完成：有数据要发送时，必需有写操作被注册，并且只能注册一次；没有数据时，不能有写操作被注册。 阅读全文

感谢林永听投递本文。  校对：方腾飞

1. 关于 C1X 标准

C1X 是 C 语言的下一个标准，用于取代现有的 C99 标准。 C1X 是一个非正式名字，该标准仍在制订中，最新的工作草案是 N1494 ，发布于 2010 年 6 月。与 C99 相比， C1X 在语言和库上有显著的变化，本文重点分析 N1494 草案中的多线程部分。

2. 呼之欲出的多线程

不瞒你说， C99 标准里面的内存模型仍然是单线程的，即所有代码都运行在一个线程（进程）内。也许，你简直不敢相信这个是真的，因为说不定你每天都与多线程打交道， 使用 _beginthread ， CreateThread 或 pthread_create 等不同平台的函数去创建线程。当你担心每个变量被编译器优化时，不得不加上 volatile 修饰符时，或者加上内存栅栏 (memory barrier) ，都印证了 C99 为单线程的内存模型。

32 位保护模式的出现，催生了多任务操作系统的诞生，随之而来的就是多线程环境。随着多核时代的到来，多线程环境成为程序开发不可逃避的问题。无锁编程，并行编程等已经成熟的技术在 C 社区里，常常给初学者遥不可及的感觉。在迫切需要多线程的时代，不同厂商和平台都纷纷开发了各自的多线程库，如 POSIX 的 pthreads 和 window 的 winThread 。软件工程师在特定的平台下，使用各自的线程库来开发多线程或并发程序，并非很难，但可移植却成了他们面临的问题。如 pthreads 在默认情况下，互斥锁是非递归的，要使用递归互斥锁，程序库必须支持一些扩展 feature ；而 window 下的锁默认情况下是递归的。 lock-wait-wakup 方式也不尽然相同，这对开发跨平台的多线程程序来说无异于雪上加霜。

放眼 C 语言的后来者，如 Java ，很早就支持了多线程，并且它的内存模型在不断地修改，以适应发挥多线程的优势。 Erlang 作为一种天生的并发编程语言，踏上编程语言的行列，成为并发编程的新星。同时，很多脚本语都内置地支持线程类或结构。 C/C++ 作为后来加入到多线程的行列，尽管已经太晚了，但对于 C 语言社区来说，这无疑是最令人兴奋的消息了。

阅读全文