IT技术博客大学习 共学习 共进步
首页 / chenssy
IT 2019-06-28 13:38:28 / 累计浏览 2,560

10分钟看懂！基于Zookeeper的分布式锁

这篇讲的是如何用Zookeeper实现一个可靠的分布式锁。 作者从分布式系统协调的核心需求——分布式锁出发，直接对比了常见的数据库、Redis与Zookeeper三种方案，重点聚焦在Zookeeper的实现上。文章首先通俗地解释了Zookeeper是什么：一个提供配置管理、分布式协同等底层服务的中心化框架，其核心是一个类似文件系统的、保存在内存中的有序树状结构。 实现分布式锁的核心思路巧妙地利用了Zookeeper的几个关键特性：**有序节点**来排队，**临时节点**来防止客户端宕机导致的死锁，以及**事件监听**来高效地通知锁的释放。基本的算法是：客户端在指定根路径下创建临时有序子节点，序号最小的获得锁；否则就监听前一个节点的删除事件，从而实现公平的等待队列。 文章还深入讨论了两个关键优化。一是如何避免“羊群效应”，即每个客户端只监听自己前一个节点，而不是所有节点变更，这大大提升了性能。二是分析了Curator这个开源库如何将这些复杂逻辑封装成简单的 `acquire()` 和 `release()` API，让开发者能轻松使用。 总的来说，这篇文章没有停留在理论，而是深入到了算法细节与源码实现，把Zookeeper利用临时有序节点解决分布式锁的精髓讲得清晰透彻。

IT 2019-04-09 00:25:32 / 累计浏览 1,960

代码不规范，同事两行泪，撸码七宗罪！

代码千万行，注释第一行；编程不规范，同事两行泪。这篇有趣的文章从技术圈广为流传的吐槽段子出发，直指协作中最令人头疼的痛点。 作者梳理了编程世界里的“七宗罪”，将那些看似不起眼、却会累积成“技术债”或团队矛盾的坏习惯一一列出。比如协作时拒绝使用版本控制，让代码合并变成一场噩梦；用 a、b、c 给变量命名，在大型项目中让人抓狂；盲目增加依赖库，甚至不经测试就升级核心组件（比如 React），可能直接引发连锁反应。文章还点名批评了不一致的代码格式、逃避错误处理（尤其要当心空指针），以及在复杂场景下选用不当的数据类型等常见问题。 这些“罪”之所以普遍，正因为它们常常被忽视。文章用生动的比喻和具体例子，提醒我们：代码的可读性与健壮性，往往就藏在这些细节里。遵守规范不仅是为了他人，更是为了一年后的自己不被自己写的代码“气哭”。

IT 2019-03-26 09:48:04 / 累计浏览 2,220

一位资深Java的阿里系公司实战面试经验，套路还是面试官的多

这是一篇阿里系Java工程师的实战面试复盘。作者以亲历者视角，详细还原了从项目经验到技术基础的多轮面试场景，生动展现了面试官如何通过层层追问，考察候选人的知识深度和临场应变能力。 文章的核心亮点在于“场景还原”与“答题策略”。在项目经验环节，作者以Netty线程模型为例，演示了如何将问题引导至自己熟悉的领域，并分享了如何描述项目难点（如业务逻辑阻塞Work线程导致QPS上不去）及解决方案。在基础知识考察部分，以线程池原理和锁机制（Synchronized/ReentrantLock/CAS）为例，揭示了面试官常见的问题链——例如从线程池核心参数一路追问到“秒杀”场景下的线程池配置，或是从CAS原理深挖到其操作系统指令实现及ABA问题。 文章并非单纯罗列知识点，而是通过真实的对话片段，点明了一个关键：面试的“套路”实则是考察思维逻辑与知识内化程度。作者提醒，即便面对不记得的细节或不了解的领域（如读写锁），诚实沟通比硬撑更重要。对于正在准备技术面试的读者而言，这篇复盘的价值在于揭示了面试背后的考察逻辑，并提供了如何梳理项目故事、应对深度追问的实用思路。

IT 2019-03-25 23:35:42 / 累计浏览 2,060

阿里面试题：为什么Map桶中个数超过8才转为红黑树

这篇讲的是一个经典的Java面试题：为什么HashMap的桶中链表长度达到8才转为红黑树？作者从一个好友的阿里面试经历切入，直接打开了源码中的注释，发现它只记录了阈值，却未解释原因。 文章的核心在于对源码“Implementation notes”的深入解读。作者指出，红黑树节点占用的空间是普通节点的两倍，因此转换是一种空间与时间的权衡。更关键的是，文章引用了源码中一段关于泊松分布的注释：在随机哈希算法下，桶中节点数量遵循特定的概率分布，链表长度达到8的概率极低（仅约千万分之六）。这从统计学角度证明了阈值8的选取并非随意，而是经过严谨计算的。 此外，文章也驳斥了一种常见但不够严谨的“性能对比”解释，强调了设计背后的科学性。通过剖析源码与概率模型，这篇文章将一个常见面试考点还原成了其严谨的设计思想，适合所有想理解Java集合框架底层优化的开发者。

IT 2019-03-25 23:29:04 / 累计浏览 1,860

删库跑路救命策略

这篇文章从作者亲身经历的“血泪教训”出发：休假期间因备份脚本的字符集设置错误，导致数据回滚失败，最终背锅降绩效。基于这次事故，作者系统梳理了MySQL误删数据的常见“坑”、预防措施以及紧急恢复方案。 预防篇提出了五条实用建议，比如将 `rm` 改为 `mv`、删除对象先 `rename` 归档、操作前善用事务与小批量验证等，核心在于培养操作习惯并保持敬畏之心。恢复篇则针对误删库表、物理文件被删、未提交事务的 `delete` 等不同场景，给出了从“立刻 kill 进程”到利用 `innodb_force_recovery` 启动恢复模式等具体的急救步骤。 文章结尾强调，无论平台如何发展，物理与逻辑备份都是不可替代的底线。这篇分享将事故复盘与实战经验结合，对所有涉及数据库操作的人员都是一次生动的安全警示。

IT 2019-01-01 20:39:34 / 累计浏览 1,860

美团面试经历，贡献出来一起学习

这篇讲的是一位程序媛分享她应聘美团大数据研发实习生的四轮技术面试经历。文章按时间顺序，详细还原了从简历筛选到最终HR面的完整过程，像一份真实的面试笔记。 面试内容覆盖面非常广。一面由部门主管在会议间隙进行，侧重项目架构与设计模式；二面长达一小时，深入考察了Spring机制、多线程、JVM内存与GC、MySQL优化等核心知识；三面是交叉面试，增加了在线编码环节；最后的HR面则异常“硬核”，面试官对项目细节和科研经历进行了深度追问。 作者在应对面试时有不少值得借鉴的思路。例如，面对不熟悉的问题（如服务器配置）坦诚相告；在解释Spring IOC/AOP时，用项目实例来证明理解；遇到不确定的技术点（如Java异步IO）时，坦然说明并向面试官展示自己的推理过程。文章也记录了面试官“边面试边给反馈”这类有助于候选人调整状态的细节。 文末，作者总结了对此次面试的反思：技术基础（算法、框架原理）需要扎实，面试中要主动引导节奏展示自己的知识体系，而对于高并发、分布式等工程经验，在校生只能通过理论学习先行铺垫。这为准备技术面试的读者提供了切实的参考。

IT 2018-12-24 23:49:43 / 累计浏览 2,040

一起来学 Spring 2.X

这是一份针对 Spring Boot 2.x 的全面学习指南，由作者唐亚峰在其个人博客上连载。系列文章从最基础的构建第一个 Spring Boot 工程讲起，为读者铺设了一条清晰的学习路径。 整个系列系统性地覆盖了 Spring Boot 2.x 开发中的核心技术栈。作者不仅详细解释了配置管理、日志框架这些基础内容，还深入到整合 Thymeleaf 模板、使用 JdbcTemplate、Spring Data Jpa 以及 MyBatis 进行数据库访问的实战环节。对于进阶需求，文章进一步探讨了如何集成 Lettuce Redis 做缓存、利用 Spring Cache 二级缓存、接入 RabbitMQ 消息队列（包括延迟队列的实现），以及使用 Swagger 进行接口在线调试。 除了核心功能集成，系列也关注应用运维与工程化实践。例如，通过 Actuator 与 Spring Boot Admin 实现服务监控与管理，配置定时任务，实现文件上传与全局异常处理，以及借助 Liquibase 进行数据库版本管理。在安全与性能方面，讲解了整合 Shiro 安全框架，使用本地锁与分布式锁防止重复提交，并探讨了分布式限流方案的优雅实现。甚至包括 JDK8 日期格式化这种实用细节和 WebSocket 聊天室搭建这样的趣味课题。 这个系列最大的特点是循序渐进且内容扎实，每一讲都聚焦一个明确的主题并提供可运行的示例，非常适合希望从零开始或系统性巩固 Spring Boot 2.x 开发技能的读者作为案头参考。

IT 2018-09-20 21:53:32 / 累计浏览 2,180

四年努力，梦归阿里，和大家聊聊成长感悟

这篇文章讲述了技术博主“五月的仓颉”在工作四年后，成功加入阿里的经历与感悟。作者从毕业初期的迷茫讲起，分享了他如何通过系统性地研究招聘需求、制定学习计划，并在一年内高强度学习JDK源码、虚拟机等核心知识，最终实现目标的具体过程。 文中重点探讨了程序员成长的阶段划分。作者认为，工作五年是一个关键节点，此时应从扎实的个人基本功（如框架原理、JVM、分布式知识等）和项目实战能力（独立处理复杂业务、排查疑难问题、带领小团队）两方面同步提升。他特别强调“深度优先、广度次之”的学习策略，即在一到两个方向上深耕，远胜于广泛涉猎但浅尝辄止。 最后，作者指出进入大厂并非终点，而是更努力的新起点。全文没有空泛的鸡汤，而是用亲身经历和技术思考，为处于成长期的程序员提供了一份清晰的路线图和真诚的鼓励。

IT 2017-10-15 09:33:08 / 累计浏览 3,000

【死磕Java并发】—–J.U.C之Java并发容器：ConcurrentLinkedQueue

这篇技术解析深入探讨了Java并发包中非阻塞线程安全队列ConcurrentLinkedQueue的实现原理。文章从线程安全队列的两种实现思路（阻塞与非阻塞）切入，重点剖析了ConcurrentLinkedQueue如何完全基于CAS算法（无锁）来实现其核心操作。 作者详细拆解了该队列必须遵循的四个关键不变性，并阐明了head与tail指针在更新时可以“滞后”的设计特性。全文的核心在于通过逐行解读offer()入列与poll()出列方法的源码，并辅以清晰的步骤图，生动展示了在多线程竞争环境下，新节点是如何被安全添加、以及头部节点如何被识别并移除的。分析中特别指出，像“p == q”这种看似异常的判断，正是处理并发删除与插入操作交错进行的关键所在，巧妙地解决了指针可能因并发更新而失效的难题。 通过这篇文章，读者能直观理解一种高性能并发容器如何在不使用锁的情况下，通过精巧的指针操作和CAS原子指令来保障线程安全与最终一致性。

IT 2017-03-01 23:15:47 / 累计浏览 3,640

【死磕Java并发】—–Java内存模型之happend-before

这篇深入探讨了Java并发编程中一个关键却容易混淆的概念：happens-before原则。作者从多线程环境下变量修改的可见性问题出发，解释了JMM如何通过happens-before来建立内存可见性的保证。 文章系统梳理了happens-before的八大核心规则，例如程序次序规则（单线程内操作有序）、volatile变量规则（写操作对后续读操作可见）以及锁定规则（解锁先于加锁）。除了这些JVM原生规则，作者还列举了诸如线程安全集合操作、Future.get()等场景下的六条推导规则，构建了完整的判断体系。 为了帮助理解，文章通过简单的代码示例，一步步演示了如何应用这些规则来判断一段非同步代码是否存在线程安全风险。它明确了happens-before的本质：它并非强制操作顺序，而是保障了在存在该关系时，一个操作的结果对另一个操作的可见性。这为我们在并发编程中分析数据竞争、设计线程安全代码提供了根本依据。

IT 2017-03-01 23:06:03 / 累计浏览 2,140

【死磕Java并发】—–Java内存模型之重排序

这篇文章深入探讨了Java内存模型中的重排序机制，解释了编译器和处理器为何以及如何在不破坏程序最终结果的前提下调整指令顺序。 作者从“as-if-serial”语义出发，结合具体代码示例（如`int a=1; int b=2; int c=a+b;`），清晰地阐述了在单线程环境下，只要不影响最终结果，操作间的顺序可以被优化重排。文章还特别指出了JVM对异常处理的特殊照顾，以确保`try-catch`块中的逻辑不被重排序破坏。 然而，文章的重点在于揭示重排序对多线程程序的潜在风险。通过一个使用了`volatile`的经典示例，作者展示了当两个线程共享变量且没有同步控制时，指令重排序（如赋值操作的顺序调换）可能导致其他线程观察到“中间状态”，从而破坏了程序预期的执行语义。这明确区分了重排序在单线程与多线程环境下的不同影响。 对于开发者而言，理解重排序是掌握Java并发编程中可见性问题的基础，它解释了为何在多线程场景下必须谨慎使用同步工具（如`volatile`或锁）来建立必要的内存屏障。

IT 2017-03-01 23:01:17 / 累计浏览 2,900

【死磕Java并发】—–Java内存模型之分析volatile

这篇讲的是volatile关键字在Java内存模型（JMM）中的深层实现原理。作者从volatile的两大核心特性——可见性与禁止重排序出发，深入剖析了JMM是如何通过“内存屏障”这一底层机制来保证这些语义的。 文章通过一个经典的`VolatileTest`代码示例，生动演示了volatile读写操作如何与happens-before原则配合，确保跨线程的数据可见性。更硬核的部分在于对内存屏障插入策略的详解：JMM采取了保守策略，在volatile读/写前后精确插入StoreStore、StoreLoad、LoadLoad、LoadStore等屏障指令，以此强制维护操作的顺序性。 但巧妙之处不止于此。作者引用《Java并发编程的艺术》中的例子进一步说明，编译器在实际执行时会进行优化，只要不破坏volatile的内存语义，就可以省略部分冗余的屏障指令。这让我们看到，JMM的实现既保证了正确性，也蕴含着对性能的考量。对于想弄清楚volatile“凭什么”能起作用的开发者来说，这篇文章从理论到图解都梳理得相当清晰。

IT 2017-03-01 22:58:18 / 累计浏览 2,140

【死磕Java并发】—–Java内存模型之从JMM角度分析DCL

这篇讲的是Java并发编程中一个经典而隐蔽的陷阱——双重检查锁定（DCL）在实现单例模式时，看似高效完美，实则潜藏因指令重排序导致的对象未初始化即被引用的严重问题。 作者从一个常见的错误懒汉式单例写法入手，逐步推导到试图优化性能的DCL写法。其核心矛盾在于：对象实例化包含“分配内存”、“初始化对象”和“引用赋值”三个步骤，而JVM或CPU可能对后两步进行重排序。这就意味着，在多线程环境下，其他线程可能看到一个已完成引用赋值、但尚未完成初始化的对象“半成品”，导致程序行为不可预期。 文章进而给出了两种标准解决方案。一种是利用`volatile`关键字的内存屏障语义，禁止实例初始化步骤的重排序，从而确保对象完全构造完毕后对其他线程才可见。另一种则是利用类加载机制，通过静态内部类延迟初始化，借助JVM对类初始化过程加锁的保证，来实现线程安全的单例。后者巧妙地将同步问题委托给了JVM本身，代码也更为简洁。 理解DCL的问题根源及解决方案，对于掌握Java内存模型中多线程可见性与指令重排序的实际影响至关重要。

IT 2017-02-06 22:52:02 / 累计浏览 2,340

【死磕Java并发】—–深入分析synchronized的实现原理

这篇讲的是Java开发者最熟悉的synchronized关键字，但深入到了它鲜为人知的底层实现。文章从开发者早期对synchronized“重量级锁”的刻板印象出发，系统剖析了JDK 1.6对其进行的一系列优化，彻底改变了这一认知。 作者首先拆解了同步代码块与同步方法在JVM字节码层面的不同实现（monitorenter/monitorexit指令与ACC_SYNCHRONIZED标志），并指出这一切的基础在于Java对象头中的Mark Word和Monitor结构。其中，Mark Word被设计成可随锁状态动态复用的高效数据结构，是理解锁升级的关键。 文章的核心价值在于清晰梳理了JVM的锁优化机制：从通过“自旋等待”避免线程频繁挂起，到引入“适应性自旋”让虚拟机智能调整等待次数；从利用逃逸分析“消除”不必要的锁，到将连续操作“粗化”为更大范围的锁。最终，重点阐释了锁状态如何从无锁、偏向锁、轻量级锁一步步升级到重量级锁的完整路径，以及每一步升级的触发条件与设计意图。这不仅是理解synchronized的百科全书，也为开发者在实际编程中合理使用同步工具提供了底层视角。

IT 2016-05-05 22:36:20 / 累计浏览 2,280

《Effective java》—–读书笔记

读完《Effective Java》后，作者结合自己的面试反思与年度学习计划，写下这篇笔记，摘录并梳理了书中多条核心原则。笔记从创建对象讲起，强调了静态工厂方法的优势、避免创建不必要对象以及如何通过私有构造器或枚举强化单例。接着，重点讨论了类与接口设计：最小化可访问性、为不可变性努力、优先使用组合而非继承、以及如何用接口定义类型和用骨架实现类弥补抽象类的不足。 在方法层面，笔记总结了慎用重载和可变参数、返回零长度数组而非null等实用建议。通用编程部分则归纳了最小化局部变量作用域、优先使用for-each循环和基本类型等性能与可读性并重的技巧。最后，笔记也提到了异常处理的原则——异常应只用于异常情况。 这些笔记摘录不仅保留了原著的精华论点，还结合了博主自己的理解，如通过WeakHashMap管理缓存、继承判断的“is-a”原则等，将“四大圣经”之一的实践智慧转化为开发者可直接参考的要点清单。

IT 2016-03-14 23:39:34 / 累计浏览 2,740

【Java并发编程实战】—– AQS(三)：阻塞、唤醒：LockSupport

这篇讲的是LockSupport如何作为AQS框架的底层原语，实现线程的阻塞与唤醒。 作者从AQS的获取与释放锁流程切入，指出当线程获取锁失败进入CLH队列后，最终是通过`parkAndCheckInterrupt()`中的`LockSupport.park(this)`挂起的；而在释放锁后，则由`unparkSuccessor()`调用`LockSupport.unpark()`来唤醒队列中的下一个节点。 文章深入解析了LockSupport的核心机制：它基于一个与线程关联的“许可”工作。`park()`会尝试获取许可，若许可不可用则线程休眠；`unpark()`则赋予许可以唤醒目标线程。这种方法比传统的`Thread.suspend()`和`resume()`更安全，因为它不会导致死锁问题。文中也提到，许可不可重入，因此`park()`与`unpark()`通常需要成对使用，并且`unpark()`需要发生在`park()`之后，否则线程不会一直阻塞，还可以通过`parkNanos()`设置超时。 实现上，两者最终都委托给`Unsafe`类的本地方法完成，这展示了Java并发包构建在更底层原语之上的设计思想。

IT 2016-03-14 23:37:10 / 累计浏览 2,820

【Java并发编程实战】—– AQS(二)：获取锁、释放锁

这篇讲的是Java并发编程中AQS（抽象队列同步器）如何实现锁的获取与释放，是对AQS底层机制的核心剖析。 作者从锁获取的核心方法 `acquire` 出发，结合源码与流程图，清晰地展示了完整流程：线程首先通过 `tryAcquire` 尝试获取锁；若失败，则通过 `addWaiter` 将自身封装为节点加入CLH队列队尾；随后在 `acquireQueued` 方法中，节点会自旋检查是否为前驱节点且能获取锁，若是则出队，否则通过 `parkAndCheckInterrupt` 挂起等待。文章特别指出了 `tryAcquire` 由具体子类（如ReentrantLock）实现，体现了模板方法模式的设计。 在锁释放部分，流程相对简洁：释放锁时调用 `release` 方法，其核心是 `tryRelease` 修改状态后，通过 `unparkSuccessor` 唤醒队列中下一个有效节点，使等待的线程得以继续尝试获取锁。 通过对 `acquire` 与 `release` 两大核心路径的拆解，这篇文章帮助读者直观理解了AQS如何以CLH队列为骨架，管理锁状态与线程等待，从而掌握ReentrantLock、Semaphore等并发工具背后的统一运行逻辑。

IT 2016-03-14 23:34:34 / 累计浏览 3,140

【Java并发编程实战】—– AQS(一)：简介

这篇讲的是Java并发编程中作为JUC同步器基石的AbstractQueuedSynchronizer（AQS）框架的核心原理。作者从ReentrantLock、CountDownLatch等同步器获取锁的不同方法出发，引出对统一框架的需求，从而介绍了AQS的诞生背景。 文章着重解析了AQS实现的三大核心机制。首先，它用一个volatile的int型state变量来表示同步状态，通过CAS操作进行原子更新，这构成了锁获取与释放的状态基础。其次，AQS内部维护了一个变种的CLH双向队列，用于管理等待线程。这个设计的巧妙之处在于，它摒弃了原始CLH的自旋，转而让节点在队列中通过状态位安全地阻塞与唤醒，并能高效处理超时和取消操作。最后，AQS通过队列中Node的SHARED和EXCLUSIVE标记，统一支持了共享锁与互斥锁两种模式。 在阻塞唤醒机制上，AQS没有沿用Java内置锁的wait/notify，而是采用了更底层的LockSupport.park()与unpark()本地方法。整篇文章清晰地勾勒出AQS的骨架，为后续深入分析各类同步器的具体实现打下了扎实的基础。

IT 2015-04-08 00:05:30 / 累计浏览 9,620

你真的了解try{ return }finally{}中的return？

这篇文章从论坛上的一个经典问题出发，探讨了Java中`try`块内的`return`语句与`finally`块交互时一个看似反直觉的行为：为什么一段简单的代码最终返回的是2而不是3？ 作者没有停留在表面结论，而是层层深入，像侦探一样剖析了整个执行流程。文章首先抛出了一连串关键问题：`try`中`return`后`finally`还会执行吗？执行顺序又是什么？接着，作者查阅了Java官方教程和JVM规范，明确指出`finally`块总会执行，并且是在方法实际返回控制权之前执行。为了验证这一点，文章通过IDE的调试模式，逐帧展示了变量`x`如何从1变为2，再在`finally`中变为3，最后却返回2的全过程。 真正的谜底藏在JVM的底层机制里：当执行`try`中的`return ++x`时，JVM会先计算返回值（即2），并将其保存在局部变量中，然后再去执行`finally`块。`finally`执行后，方法最终返回的是之前缓存的那个值，而不是被`finally`修改后的当前变量值。文章最后甚至通过分析字节码指令来巩固这一结论。对于任何想透彻理解Java异常处理与返回值机制细节的开发者来说，这篇文章都提供了一次清晰而深入的“解剖”示范。

IT 2015-02-26 22:43:07 / 累计浏览 2,160

java中文乱码解决之道（八）—–解决URL中文乱码问题

你是否在Java开发中，被URL传递中文参数时出现的“问号”乱码困扰过？这篇文章专门拆解这个棘手问题。作者指出，相比于表单提交，URL编码因涉及浏览器、操作系统和字符集等多种因素，情况更为复杂。核心解决思路是**主动控制编码**，避免浏览器“自由发挥”。 文章主要提供了两种实战方案。一是通过JavaScript前端编码，使用 `encodeURI` 等方法在请求发出前就对中文进行标准化处理，文章还详细对比了一次转码和二次转码在Java后台的解码方式差异。二是在服务端使用Filter过滤器，无论是直接设置请求编码格式，还是在过滤器中自动完成反编码并重新封装请求，都能有效拦截和处理乱码。每种方案都附有具体代码和配置示例，可直接复用。 无论你是正在排查此类问题，还是想从源头建立规范，文中这些经过验证的方法，能帮你一劳永逸地搞定URL中文乱码。