杨坤的博客

原创 volatile 为什么保障了可见性 不能保障多线程安全，不结合storebuffer 讲解都是耍流氓

这种情况的话 ，MESI协议同时只能一个cache是M状态，你数据在storebuffer里表示此时你的状态是M，写完就强刷cache了，顺带刷内存 所以最终结果是正确的。总结：问题就出在 如果操作化成多步骤的情况下 （上面是 a+1）,其中a+1的操作不会去刷内存导致最终结果出问题。假如在 a+1的时候 ，别的cpu 可能已经修改了a的值。而a=a+1，相当于是temp=a+1；a+1不会刷内存，a=temp才会刷。a 以 volatile 修饰。1. 以 a=a+1 为例。2.以 a=10 为例。

原创 线程池详细步骤解析

线程池示例目录1.一开始线程池中无线程2.开始新增线程数直到核心线程数3.超过核心线程数，开始往队列中塞4.队列满了，开始新增线程数到最大线程数5.再来线程，根据拒绝策略进行拒绝

原创 threadlocal 解析

目录1.为什么要解析threadlocal2.threadlocal 有什么用？3.简单示例 主要就是 set ，get方法4.源码解析综上所述 可以总结下5.内存泄漏问题6.内存泄漏如何解决1.为什么要解析threadlocal因为经常用。。。特别的重要2.threadlocal 有什么用？作为每个线程 独有的本地缓存使用。。。比如用在 用户登录后保存的用户信息等3.简单示例 主要就是 set ，get方法package com.im.

原创 线程 interrupted 详细解析

目录1.为什么这个方法值得我写个文章。？2.先看下例子3. 研究下 下面3个方法的jvm层面实现 跟用法3.1）thread.isInterrupted()3.2）thread.interrupt();3.3）Thread.interrupted()4.最后代码验证下1.为什么这个方法值得我写个文章。？ 因为这个方法跟我们的字面意思不太一样。。。。我们想当然的以为 这个就是打断线程。。实际上不是2.先看下例子package com....

原创 synchronized 详细解析

1.synchronized 是锁方法好 还是锁代码块好 根据业务需要，锁哪里都一样，关键是看 锁的对象是谁？ 只有同一把锁 才能串行话。 可以看看下面的demo例子说明。

原创 线程thread 中join方法解读

目录1.join的作用就是，调用join的线程等一等，等我跑完，你再继续跑。2.我们看到 线程退出都干了什么3.跳转到2114行 可以看到这里就是处理join方法的​编辑4.跳转到ensure_join 中，可以看到这里会notify所有持有本线程锁的线程。​编辑1.join的作用就是，调用join的线程等一等，等我跑完，你再继续跑。通常用在比如主线程登录子线程跑完再跑。那么原理如何呢？ 看源码可以看到实际上是调用的wait（）方法。public final s..

原创 三大队列cxq，entrylist，waitset 个人理解分析

1.synchronized，wait（），notify（）方法等这些功能底层怎么实现的呢？其实就是操控cxq，entrylist，waitset这三大队列从而实现的。所以有必要好好的梳理下entrylist 是双向链表2.synchronized 重锁的时候，进行抢锁的流程怎么样的呢？大家都知道重量级锁就是各个线程通过cas去修改ObjectMonitor中ower字段，谁修改成功表示谁抢到锁了，如果失败了会cas加入cxq中，cxq是栈结构。3.wait（）方法会使得当前的线程进

原创 volatile机制 详细解读，原理一步一步分析

volatile 大家都知道，可见性，禁止重排序，不是原子性。其他的呢？好像没了 紧紧停留在八股文上。！今天就好好缕缕思路。正确理解volatile的姿势：单cpu架构->cpu多级cache结构 -> **缓存一致性协议（MESI）-> store buffer和invalidate queue引入 ->造成mesi协议不一致了**-> 内存屏障-->volatile-->mesi协议再次一致1.单cpu架构现在已经被淘汰了2.多cpu.

原创 线程类api详解

目录1.构造器 先看看线程类的构造器2线程优先级3守护线程4钩子线程5异常处理6.其他方法1.构造器 先看看线程类的构造器选个方法最多的看看public Thread(ThreadGroup var1, Runnable var2, String var3, long var4) { this.init(var1, var2, var3, var4);}1.ThreadGroup 线程组，就是线程可以编组，组上又可以编组

原创 java 协程，线程直接的区别，实际测试两者间效率

目录1.协程的切换者是用户（编程者或应用程序），切换时机是用户自己的程序所决定的。协程的切换内容是硬件上下文，切换内存保存在用户自己的变量（用户栈或堆）中。协程的切换过程只有用户态，即没有陷入内核态，因此切换效率高。2.目前现状3.代码测试 协程 vs线程 效率线程：协程：debug协程线程什么情况总结：1.协程的切换者是用户（编程者或应用程序），切换时机是用户自己的程序所决定的。协程的切换内容是硬件上下文，切换内存保存在用户自己的变量（用户栈或堆）中。协程的切换

原创 进程，线程，协程概念和区别

目录1.进程是应用程序的启动实例，进程拥有代码和打开的文件资源、数据资源、独立的内存空间。2.操作系统中的进程和线程3.线程的状态4.进程与线程的区别5.进程、线程、协程的对比6.上下文切换1.进程是应用程序的启动实例，进程拥有代码和打开的文件资源、数据资源、独立的内存空间。线程从属于进程，是程序的实际执行者，一个进程至少包含一个主线程，也可以有更多的子线程，线程拥有自己的栈空间。2.操作系统中的进程和线程对操作系统而言，线程是最小的执行单元，..

原创 jvm源码debug native方法，并手写自定义线程，实现对java侧run方法回调

目录回顾 thread 的start0 方法，我们简化下，其实就是 调用 内核线程 pthread_create ，然后这个方法等待 java_start 方法执行，java_start 方法回调 java端run方法。2.手写模拟过程java端 我们写个类2) 可以看到 start0 就是 native方法 ，完全模拟thread的调用过程3）生成的.h 文件处理4）编写 c++文件5）将上述 2个文件 放我们的linux服务器上 ，为了方便我直接放 openjdk 的bi

原创 源码debug 线程start0 方法，一步一步debug，java openjdk 源码解析 职场进阶

目录1为什么要看这个源码2. debug 步骤 1.1既然是thread 类，我们先看到 thread.c 中找1.2既然是 jvm的，就在jvm.cpp上打断点了 2817行3我们跳入到 2851行4可以看出 这里是javaThread的一个构造方法 ，我们进去 thread.cpp 1570 行5java_start 方法是在哪里呢？ os_linux.cpp 806行，我们看看这个方法到底在干嘛6还记得创建线程是哪里吗 ？jvm.cpp 2851 行，我们接...

原创 java main 源码分析流程，老鸟你会了吗？全网最详细

为什么要研究main 作为java的程序入口，作为java程序员不能对源码的流程一点都不了解吧。另外main的流程也是比较经典的源码debug分析，流程还是比较容易理解并学习的。 2.大体猜想，并带着疑问源码debug 其他的方法都是可以明显看出代码调用的，main没有。。。那肯定是jvm帮我们创建的 main也是作为一个线程，那线程实际是在哪里呢？java层面吗？ 肯定不可能。为什么呢？ 线程是有cpu 调度的最小执行单元，请问jvm有cpu吗？所以总结一句话 jav...

原创 Windows 如何远程调试openjdk 源码 gdbserver gdb 老鸟们真的会了吗

原创 linux 中搭建openjdk

linux 中搭建openjdk有喜欢技术的 可以加群，专注java底层开发本机环境：虚拟机 3.10.0-1160.el7.x86_64 （linux系统 x86） 准备工作 需要准备个需要准备一个boot jdk，也就是前导jdk，这个jdk是用来引导编译的，比如我们要编译jdk8，那这时候系统里要预先安装一个jdk7。 安装必要的工具集 yum install -y zipyum groupinstall -y "Development Tools"y