Java
232 篇笔记
- 6.21 Kernel_level_threadhistorical
1. 是什么 User level thread是操作系统感知不到的,由应用程序自己创建的线程并负责调度 Kernel level thread是操作系统能感知到的,并由操作系统负责调度 2. 如何验证Java线程是kernel级别的 Kernel level thread. Java程序通过JVM
- 6.22 Unsafehistorical
1. 是什么 Unsafe类顾名思义是个不安全的类,为什么说他不安全呢?我们得从C语言的内存管理说起。 1.1. C语言的内存管理 C语言中每个变量在内存中都有一个地址,我们可以用 &变量名 获取这个地址,然后用指针变量进行接收。说白了指针保存的就是内存地址。 我们要使用一段内存的时候需要用 mal
- 6.23 再谈JMMhistorical
了解了计算机底层知识后,再来看JMM就容易多了 1. 为什么需要JMM 之前提到过内存模型规定了程序的内存操作(读操作和写操作)所有可能的执行顺序中哪些是正确的,而不同的处理器架构有不同的内存模型,Java作为一个跨平台(OS和硬件)的语言,为了屏蔽底层的这些差异,定义了自己的内存模型:JMM 2.
- 6.24 锁的优化historical
1. JVM对锁的优化 JDK1.5之前sychronized内部锁的效率很低,1.5之后做了大量优化,提升了锁的性能。 优化措施主要有以下几个: 1.1. 锁的消除 JIT(不是javac)借助逃逸分析以及内联技术,分析某个同步代码块是否只能被一个线程访问, 是的话则不生成monitor相关的字节
- 6.25 手写AQShistorical
我们可以自己动手写一个简单的AQS,以更好地理解AQS实际的源码 1. 需求 1. 锁是排他的,一旦这个锁被某个线程占有,只要这个锁没被释放,他就不能被其他线程占有。因此需要保存当前占有锁的线程 2. 要有一个单独的字段表示当前锁的状态,是空闲还是已被占有 3. 同一时间有很多线程抢占锁,只有一个线
- 6.26 公平锁historical
所谓公平锁,遵循先到先得的原则。 即使锁已经被释放了,后到的也不能去抢占锁,得等到前面没人时才能去获取 1. 如何使用 2. 原理分析 2.1. 构造方法 2.1.1. 底层使用AQS实现 2.2. 加锁 - lock 2.2.1. 调用公平锁的lock方法 - FairSync.lock 2.2.
- 6.27 BlockingQueuehistorical
1. 是什么 线程安全的阻塞队列。 特点: - 先进先出: 既然是队列那肯定是先进先出 - 阻塞 支持在插入元素时,如果队列已满,那么阻塞,等待队列非满 也支持在删除元素时,如果队列为空,那么阻塞,等待队列非空 - 无界有界 数组容量的大小。无界其实是Integer.MAX VALUE - 线程安全
- 6.28 Executorshistorical
1. 使用 2. newCachedThreadPool 3. newScheduledThreadPool 4. newFixedThreadPool 5. newSingleThreadExecutor
- 6.29 JDK1.8的ConcurrentHashMaphistorical
1. 是什么 线程安全的HashMap,底层使用sychronized+CAS+HashMap的结构(数组+链表+红黑树)实现 2. 如何使用 3. 原理分析 3.1. 构造方法 3.1.1. Node 3.2. put方法【有加锁】 - putVal - 4行:计算key的hash,这里不是简单得
- 6.30 生产者消费者historical
1. 使用BlockingQueue 2. 使用wait notify 3. 使用Lock Condition 相比于上面的wait notify这里用了两个condition,这样子唤醒的时候就不会把生产者和消费者一起唤醒,只唤醒某一个即可(即生产者唤醒消费者,消费者唤醒生产者)