死磕 Java
0 人感兴趣 · 28 次引用
- 最新
- 推荐
Spring 扩展之自定义类型转换器
在上篇文章中小编分析了 Spring ConversionService 类型转换体系，相信各位都对其有了一个清晰的认识，这篇博客将利用 ConversionService 体系来实现自己的类型转换器。
Spring 扩展之深入分析 Bean 的类型转换体系
我们知道不管 bean 对象里面的属性时什么类型，他们都是通过 XML 、Properties 或者其他方式来配置这些属性对象类型的。在 Spring 容器加载过程中，这些属性都是以 String 类型加载进容器的，但是最终都需要将这些 String 类型的属性转换 Bean 对象属性所对应
Spring 扩展之深入分析 PropertyOverrideConfigurer
在文章 【死磕 Spring】----- IOC 之 深入分析 BeanFactoryPostProcessor z中提到，BeanFactoryPostProcessor 作用与 bean 完成加载之后与 bean 实例化之前，是 Spring 提供的一种强大的扩展机制，他有两个重要的子类，一个是 PropertyPlaceholderConfigurer
Spring 扩展之之 PropertyPlaceholderConfigurer 的应用
在博客 【死磕 Spring】----- IOC 之 深入分析 PropertyPlaceholderConfigurer 中了解了 PropertyPlaceholderConfigurer 内部实现原理，她允许我们在 XML 配置文件中使用占位符并将这些占位符所代表的资源单独配置到简单的 properties 文件中来加载。这个特性
Spring 扩展之深入分析 PropertyPlaceholderConfigurer
在上文 【死磕 Spring】----- IOC 之 深入分析 BeanFactoryPostProcessor 介绍了 BeanFactoryPostProcessor，知道 BeanFactoryPostProcessor 作用域容器启动阶段，可以对解析好的 BeanDefinition 进行定制化处理，而其中 PropertyPlaceholderConfigurer 是其
Spring 扩展之深入分析 BeanFactoryPostProcessor
在博客 【死磕 Spring】----- IOC 之 深入分析 BeanPostProcessor 深入介绍了 BeanPostProcessor 的实现机制。在这篇文章中提到 BeanPostProcessor 是 Spring 提供一种扩展机制，该机制允许我们在 Bean 实例化之后初始化之际对 Bean 进行增强处理（前、后置处
Spring 扩展之深入分析 InitializingBean 和 init-method
Spring 在 bean 初始化时进行三个检测扩展，也就是说我们可以对 bean 进行三个不同的定制化处理，前面两篇博客 【死磕 Spring】----- IOC 之 深入分析 Aware 接口 和 【死磕 Spring】----- IOC 之 深入分析 BeanPostProcessor 已经分析了 Aware 接口族 和 Be
Spring 扩展之深入分析 BeanPostProcessor
Spring 作为优秀的开源框架，它为我们提供了丰富的可扩展点，除了前面提到的 Aware 接口，还包括其他部分，其中一个很重要的就是 BeanPostProcessor。这篇文章主要介绍 BeanPostProcessor 的使用以及其实现原理。我们先看 BeanPostProcessor 的定位：
【死磕 Java 并发】-----J.U.C 之深入分析 CAS
CAS，Compare And Swap，即比较并交换。Doug lea大神在同步组件中大量使用CAS技术鬼斧神工地实现了Java多线程的并发操作。整个AQS同步组件、Atomic原子类操作等等都是以CAS实现的，甚至ConcurrentHashMap在1.8的版本中也调整为了CAS+Synchronized。可以说CAS
【死磕 Java 并发】-----J.U.C 之 Condition
在没有Lock之前，我们使用synchronized来控制同步，配合Object的wait()、notify()系列方法可以实现等待/通知模式。在Java SE5后，Java提供了Lock接口，相对于Synchronized而言，Lock提供了条件Condition，对线程的等待、唤醒操作更加详细和灵活。下图是Condi
【死磕 Java 并发】-----J.U.C 之读写锁：ReentrantReadWriteLock
重入锁ReentrantLock是排他锁，排他锁在同一时刻仅有一个线程可以进行访问，但是在大多数场景下，大部分时间都是提供读服务，而写服务占有的时间较少。然而读服务不存在数据竞争问题，如果一个线程在读时禁止其他线程读势必会导致性能降低。所以就提供了读写
【死磕 Java 并发】-----J.U.C 之 AQS：阻塞和唤醒线程
在线程获取同步状态时如果获取失败，则加入CLH同步队列，通过通过自旋的方式不断获取同步状态，但是在自旋的过程中则需要判断当前线程是否需要阻塞，其主要方法在acquireQueued()：
【死磕 Java 并发】-----J.U.C 之 AQS：同步状态的获取与释放
在前面提到过，AQS是构建Java同步组件的基础，我们期待它能够成为实现大部分同步需求的基础。AQS的设计模式采用的模板方法模式，子类通过继承的方式，实现它的抽象方法来管理同步状态，对于子类而言它并没有太多的活要做，AQS提供了大量的模板方法来实现同步
【死磕 Java 并发】-----J.U.C 之 AQS：CLH 同步队列
在上篇博客【死磕Java并发】-----J.U.C之AQS：AQS简介中提到了AQS内部维护着一个FIFO队列，该队列就是CLH同步队列。
【死磕 Java 并发】-----J.U.C 之 AQS：AQS 简介
Java的内置锁一直都是备受争议的，在JDK 1.6之前，synchronized这个重量级锁其性能一直都是较为低下，虽然在1.6后，进行大量的锁优化策略（【死磕Java并发】-----深入分析synchronized的实现原理）,但是与Lock相比synchronized还是存在一些缺陷的：虽然synch
【死磕 Java 并发】-----Java 内存模型之总结
经过四篇博客阐述，我相信各位对Java内存模型有了最基本认识了，下面LZ就做一个比较简单的总结。
【死磕 Java 并发】-----Java 内存模型之从 JMM 角度分析 DCL
DCL，即Double Check Lock，中卫双重检查锁定。其实DCL很多人在单例模式中用过，LZ面试人的时候也要他们写过，但是有很多人都会写错。他们为什么会写错呢？其错误根源在哪里？有什么解决方案？下面就随LZ一起来分析
【死磕 Java 基础】 — 谈谈那个写时拷贝技术 (copy-on-write)
copy-on-write，即写时复制技术，这是小编在学习 Redis 持久化时看到的一个概念，当然在这个概念很早就碰到过（Java 容器并发有这个概念），但是一直都没有深入研究过，所以趁着这次机会对这个概念深究下。所以写篇文章记录下。
【死磕 Java 并发】-----Java 内存模型之重排序
在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件：
【死磕 Java 并发】-----Java 内存模型之 happens-before
在上篇博客（【死磕Java并发】-----深入分析volatile的实现原理）LZ提到过由于存在线程本地内存和主内存的原因，再加上重排序，会导致多线程环境下存在可见性的问题。那么我们正确使用同步、锁的情况下，线程A修改了变量a何时对线程B可见？
【死磕 NIO】— NIO 基础详解
Netty 是基于Java NIO 封装的网络通讯框架，只有充分理解了 Java NIO 才能理解好Netty的底层设计。Java NIO 由三个核心组件组件：
【死磕 Java 并发】—–深入分析 volatile 的实现原理
通过前面一章我们了解了synchronized是一个重量级的锁，虽然JVM对它做了很多优化，而下面介绍的volatile则是轻量级的synchronized。如果一个变量使用volatile，则它比使用synchronized的成本更加低，因为它不会引起线程上下文的切换和调度。Java语言规范对vo
【死磕 Java 并发】----- 深入分析 synchronized 的实现原理
记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized，相对于当时的我们来说synchronized是这么的神奇而又强大，那个时候我们赋予它一个名字“同步”，也成为了我们解决多线程情况的百试不爽的良药。但是，随着我们学习的进行我们知道synchronize
