【并发编程】【17】【共享模型之工具】JUC ReentrantReadWriteLock 缓存应用 读写锁原理 StampedLock

已于 2023-03-20 02:19:47 修改
阅读量80 收藏
点赞数
分类专栏： JUC 文章标签： 缓存 数据库 java
于 2023-03-20 02:19:29 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_41405524/article/details/129659757
版权

8. 共享模型之工具

8.2 J.U.C

3. 读写锁

3.1 ReentrantReadWriteLock

当读操作远远高于写操作时，这时候使用 读写锁 让 读-读 可以并发，提高性能。 类似于数据库中的 select …from … lock in share mode

提供一个 数据容器类 内部分别使用读锁保护数据的 read() 方法，写锁保护数据的 write() 方法

class DataContainer {
    private Object data;
    private ReentrantReadWriteLock rw = new ReentrantReadWriteLock();
    private ReentrantReadWriteLock.ReadLock r = rw.readLock();
    private ReentrantReadWriteLock.WriteLock w = rw.writeLock();
    
    public Object read() {
        log.debug("获取读锁...");
        r.lock();
        try {
            log.debug("读取");
            sleep(1);
            return data;
        } finally {
            log.debug("释放读锁...");
            r.unlock();
        }
    }
    
    public void write() {
        log.debug("获取写锁...");
        w.lock();
        try {
            log.debug("写入");
            sleep(1);
        } finally {
            log.debug("释放写锁...");
            w.unlock();
        }
    }
}

测试 读锁-读锁 可以并发

DataContainer dataContainer = new DataContainer();
new Thread(() -> {
    dataContainer.read();
}, "t1").start();

new Thread(() -> {
    dataContainer.read();
}, "t2").start();

输出结果，从这里可以看到 Thread-0 锁定期间，Thread-1 的读操作不受影响

14:05:14.341 c.DataContainer [t2] - 获取读锁... 
14:05:14.341 c.DataContainer [t1] - 获取读锁... 
14:05:14.345 c.DataContainer [t1] - 读取
14:05:14.345 c.DataContainer [t2] - 读取
14:05:15.365 c.DataContainer [t2] - 释放读锁... 
14:05:15.386 c.DataContainer [t1] - 释放读锁...

测试 读锁-写锁 相互阻塞

DataContainer dataContainer = new DataContainer();
new Thread(() -> {
    dataContainer.read();
}, "t1").start();

Thread.sleep(100);
new Thread(() -> {
    dataContainer.write();
}, "t2").start();

输出结果

14:04:21.838 c.DataContainer [t1] - 获取读锁... 
14:04:21.838 c.DataContainer [t2] - 获取写锁... 
14:04:21.841 c.DataContainer [t2] - 写入
14:04:22.843 c.DataContainer [t2] - 释放写锁... 
14:04:22.843 c.DataContainer [t1] - 读取
14:04:23.843 c.DataContainer [t1] - 释放读锁...

写锁-写锁 也是相互阻塞的，这里就不测试了

注意事项

  • 读锁不支持条件变量

  • 重入时升级不支持：即持有读锁的情况下去获取写锁，会导致获取写锁永久等待

r.lock();
try {
    // ...
    w.lock();
    try {
        // ...
    } finally{
        w.unlock();
    }
} finally{
    r.unlock();
}
  • 重入时降级支持：即持有写锁的情况下去获取读锁
class CachedData {
    Object data;
    // 是否有效，如果失效，需要重新计算 data
    volatile boolean cacheValid;
    final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
    
    void processCachedData() {
        rwl.readLock().lock();
        if (!cacheValid) {
            // 获取写锁前必须释放读锁
            rwl.readLock().unlock();
            rwl.writeLock().lock();
            try {
                // 判断是否有其它线程已经获取了写锁、更新了缓存, 避免重复更新
                if (!cacheValid) {
                    data = ...
                        cacheValid = true;
                }
                // 降级为读锁, 释放写锁, 这样能够让其它线程读取缓存
                rwl.readLock().lock();
            } finally {
                rwl.writeLock().unlock();
            }
        }
        
        // 自己用完数据, 释放读锁 
        try {
            use(data);
        } finally {
            rwl.readLock().unlock();
        }
    }
}
* 应用之缓存
1. 缓存更新策略

更新时，是先清缓存还是先更新数据库

先清缓存

image-20230319215113397

先更新数据库

image-20230319215131142

补充一种情况，假设查询线程 A 查询数据时恰好缓存数据由于时间到期失效，或是第一次查询

image-20230319215148743

这种情况的出现几率非常小，见 facebook 论文

2. 读写锁实现一致性缓存

使用读写锁实现一个简单的按需加载缓存

class GenericCachedDao<T> {
    // HashMap 作为缓存非线程安全, 需要保护
    HashMap<SqlPair, T> map = new HashMap<>();

    ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); 
    GenericDao genericDao = new GenericDao();
    
    public int update(String sql, Object... params) {
        SqlPair key = new SqlPair(sql, params);
        // 加写锁, 防止其它线程对缓存读取和更改
        lock.writeLock().lock();
        try {
            int rows = genericDao.update(sql, params);
            map.clear();
            return rows;
        } finally {
            lock.writeLock().unlock();
        }
    }
    
    public T queryOne(Class<T> beanClass, String sql, Object... params) {
        SqlPair key = new SqlPair(sql, params);
        // 加读锁, 防止其它线程对缓存更改
        lock.readLock().lock();
        try {
            T value = map.get(key);
            if (value != null) {
                return value;
            }
        } finally {
            lock.readLock().unlock();
        }
        // 加写锁, 防止其它线程对缓存读取和更改
        lock.writeLock().lock();
        try {
            // get 方法上面部分是可能多个线程进来的, 可能已经向缓存填充了数据
            // 为防止重复查询数据库, 再次验证
            T value = map.get(key);
            if (value == null) {
                // 如果没有, 查询数据库
                value = genericDao.queryOne(beanClass, sql, params);
                map.put(key, value);
            }
            return value;
        } finally {
            lock.writeLock().unlock();
        }
    }
    
    // 作为 key 保证其是不可变的
    class SqlPair {
        private String sql;
        private Object[] params;
        public SqlPair(String sql, Object[] params) {
            this.sql = sql;
            this.params = params;
        }
        
        @Override
        public boolean equals(Object o) {
            if (this == o) {
                return true;
            }
            if (o == null || getClass() != o.getClass()) {
                return false;
            }
            SqlPair sqlPair = (SqlPair) o;
            return sql.equals(sqlPair.sql) &&
                Arrays.equals(params, sqlPair.params);
        }
        
        @Override
        public int hashCode() {
            int result = Objects.hash(sql);
            result = 31 * result + Arrays.hashCode(params);
            return result;
        }
    }
}

注意

  • 以上实现体现的是读写锁的应用，保证缓存和数据库的一致性，但有下面的问题没有考虑

  • 适合读多写少，如果写操作比较频繁，以上实现性能低

  • 没有考虑缓存容量

  • 没有考虑缓存过期

  • 只适合单机

  • 并发性还是低，目前只会用一把锁

  • 更新方法太过简单粗暴，清空了所有 key（考虑按类型分区或重新设计 key）

  • 乐观锁实现：用 CAS 去更新

* 读写锁原理
1. 图解流程

读写锁用的是同一个 Sycn 同步器，因此等待队列、state 等也是同一个

t1 w.lock，t2 r.lock

1） t1 成功上锁，流程与 ReentrantLock 加锁相比没有特殊之处，不同是写锁状态占了 state 的低 16 位，而读锁使用的是 state 的高 16 位

image-20230319222617768

2）t2 执行 r.lock，这时进入读锁的 sync.acquireShared(1) 流程，首先会进入 tryAcquireShared 流程。如果有写锁占据，那么 tryAcquireShared 返回 -1 表示失败

tryAcquireShared 返回值表示

  • -1 表示失败
  • 0 表示成功，但后继节点不会继续唤醒
  • 正数表示成功，而且数值是还有几个后继节点需要唤醒，读写锁返回 1

image-20230319222706863

3）这时会进入 sync.doAcquireShared(1) 流程，首先也是调用 addWaiter 添加节点，不同之处在于节点被设置为Node.SHARED 模式而非 Node.EXCLUSIVE 模式，注意此时 t2 仍处于活跃状态

image-20230319222724139

4）t2 会看看自己的节点是不是老二，如果是，还会再次调用 tryAcquireShared(1) 来尝试获取锁

5）如果没有成功，在 doAcquireShared 内 for (;😉 循环一次，把前驱节点的 waitStatus 改为 -1，再 for (;😉 循环一次尝试 tryAcquireShared(1) 如果还不成功，那么在 parkAndCheckInterrupt() 处 park

image-20230319222743437

t3 r.lock, t4 w.lock

这种状态下，假设又有 t3 加读锁和 t4 加写锁，这期间 t1 仍然持有锁，就变成了下面的样子

image-20230319222802612

t1 w.unlock

这时会走到写锁的 sync.release(1) 流程，调用 sync.tryRelease(1) 成功，变成下面的样子

image-20230319222816911

接下来执行唤醒流程 sync.unparkSuccessor，即让老二恢复运行，这时 t2 在 doAcquireShared 内parkAndCheckInterrupt() 处恢复运行

这回再来一次 for (;😉 执行 tryAcquireShared 成功则让读锁计数加一

image-20230319222835737

这时 t2 已经恢复运行，接下来 t2 调用 setHeadAndPropagate(node, 1)，它原本所在节点被置为头节点

image-20230319222851883

事情还没完，在 setHeadAndPropagate 方法内还会检查下一个节点是否是 shared，如果是则调用doReleaseShared() 将 head 的状态从 -1 改为 0 并唤醒老二，这时 t3 在 doAcquireShared 内parkAndCheckInterrupt() 处恢复运行

image-20230319222918783

这回再来一次 for (;😉 执行 tryAcquireShared 成功则让读锁计数加一

image-20230319222932802

这时 t3 已经恢复运行，接下来 t3 调用 setHeadAndPropagate(node, 1)，它原本所在节点被置为头节点

image-20230319222950083

下一个节点不是 shared 了，因此不会继续唤醒 t4 所在节点

t2 r.unlock, t3 r.unlock

t2 进入 sync.releaseShared(1) 中，调用 tryReleaseShared(1) 让计数减一，但由于计数还不为零

image-20230319223012151

t3 进入 sync.releaseShared(1) 中，调用 tryReleaseShared(1) 让计数减一，这回计数为零了，进入doReleaseShared() 将头节点从 -1 改为 0 并唤醒老二，即

image-20230319223027621

之后 t4 在 acquireQueued 中 parkAndCheckInterrupt 处恢复运行，再次 for (;😉 这次自己是老二，并且没有其他竞争，tryAcquire(1) 成功，修改头结点，流程结束

image-20230319223044690

2. 源码分析

写锁上锁流程

static final class NonfairSync extends Sync {
    // ... 省略无关代码

    // 外部类 WriteLock 方法, 方便阅读, 放在此处
    public void lock() {
        sync.acquire(1);
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    public final void acquire(int arg) {
        if (
            // 尝试获得写锁失败
            !tryAcquire(arg) &&
            // 将当前线程关联到一个 Node 对象上, 模式为独占模式
            // 进入 AQS 队列阻塞
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
        ) {
            selfInterrupt();
        }
    }

    // Sync 继承过来的方法, 方便阅读, 放在此处
    protected final boolean tryAcquire(int acquires) {
        // 获得低 16 位, 代表写锁的 state 计数
        Thread current = Thread.currentThread();
        int c = getState();
        int w = exclusiveCount(c);

        if (c != 0) {
            if (
                // c != 0 and w == 0 表示有读锁, 或者
                w == 0 ||
                // 如果 exclusiveOwnerThread 不是自己
                current != getExclusiveOwnerThread()
            ) {
                // 获得锁失败
                return false;
            }
            // 写锁计数超过低 16 位, 报异常
            if (w + exclusiveCount(acquires) > MAX_COUNT)
                throw new Error("Maximum lock count exceeded");
            // 写锁重入, 获得锁成功
            setState(c + acquires);
            return true;
        } 
        if (
            // 判断写锁是否该阻塞, 或者
            writerShouldBlock() ||
            // 尝试更改计数失败
            !compareAndSetState(c, c + acquires)
        ) {
            // 获得锁失败
            return false;
        }
        // 获得锁成功
        setExclusiveOwnerThread(current);
        return true;
    }

    // 非公平锁 writerShouldBlock 总是返回 false, 无需阻塞
    final boolean writerShouldBlock() {
        return false;
    }
}

写锁释放流程

static final class NonfairSync extends Sync {
    // ... 省略无关代码

    // WriteLock 方法, 方便阅读, 放在此处
    public void unlock() {
        sync.release(1);
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    public final boolean release(int arg) {
        // 尝试释放写锁成功
        if (tryRelease(arg)) {
            // unpark AQS 中等待的线程
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

    // Sync 继承过来的方法, 方便阅读, 放在此处
    protected final boolean tryRelease(int releases) {
        if (!isHeldExclusively())
            throw new IllegalMonitorStateException();
        int nextc = getState() - releases;
        // 因为可重入的原因, 写锁计数为 0, 才算释放成功
        boolean free = exclusiveCount(nextc) == 0;
        if (free) {
            setExclusiveOwnerThread(null);
        }
        setState(nextc);
        return free;
    }
}

读锁上锁流程

static final class NonfairSync extends Sync {

    // ReadLock 方法, 方便阅读, 放在此处
    public void lock() {
        sync.acquireShared(1);
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    public final void acquireShared(int arg) {
        // tryAcquireShared 返回负数, 表示获取读锁失败
        if (tryAcquireShared(arg) < 0) {
            doAcquireShared(arg);
        }
    }

    // Sync 继承过来的方法, 方便阅读, 放在此处
    protected final int tryAcquireShared(int unused) {
        Thread current = Thread.currentThread();
        int c = getState();
        // 如果是其它线程持有写锁, 获取读锁失败
        if ( 
            exclusiveCount(c) != 0 &&
            getExclusiveOwnerThread() != current
        ) {
            return -1;
        }
        int r = sharedCount(c);
        if (
            // 读锁不该阻塞(如果老二是写锁，读锁该阻塞), 并且
            !readerShouldBlock() &&
            // 小于读锁计数, 并且
            r < MAX_COUNT &&
            // 尝试增加计数成功
            compareAndSetState(c, c + SHARED_UNIT)
        ) {
            // ... 省略不重要的代码
            return 1;
        }
        return fullTryAcquireShared(current);
    }

    // 非公平锁 readerShouldBlock 看 AQS 队列中第一个节点是否是写锁
    // true 则该阻塞, false 则不阻塞
    final boolean readerShouldBlock() {
        return apparentlyFirstQueuedIsExclusive();
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    // 与 tryAcquireShared 功能类似, 但会不断尝试 for (;;) 获取读锁, 执行过程中无阻塞
    final int fullTryAcquireShared(Thread current) {
        HoldCounter rh = null;
        for (;;) {
            int c = getState();
            if (exclusiveCount(c) != 0) {
                if (getExclusiveOwnerThread() != current)
                    return -1;
            } else if (readerShouldBlock()) {
                // ... 省略不重要的代码
            }
            if (sharedCount(c) == MAX_COUNT)
                throw new Error("Maximum lock count exceeded");
            if (compareAndSetState(c, c + SHARED_UNIT)) {
                // ... 省略不重要的代码
                return 1;
            }
        }
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    private void doAcquireShared(int arg) {
        // 将当前线程关联到一个 Node 对象上, 模式为共享模式
        final Node node = addWaiter(Node.SHARED);
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();
                if (p == head) {
                    // 再一次尝试获取读锁
                    int r = tryAcquireShared(arg);
                    // 成功
                    if (r >= 0) {
                        // ㈠
                        // r 表示可用资源数, 在这里总是 1 允许传播
                        //（唤醒 AQS 中下一个 Share 节点）
                        setHeadAndPropagate(node, r);
                        p.next = null; // help GC
                        if (interrupted)
                            selfInterrupt();
                        failed = false;
                        return;
                    }
                }
                if (
                    // 是否在获取读锁失败时阻塞（前一个阶段 waitStatus == Node.SIGNAL）
                    shouldParkAfterFailedAcquire(p, node) &&
                    // park 当前线程
                    parkAndCheckInterrupt()
                ) {
                    interrupted = true;
                }
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

    // ㈠ AQS 继承过来的方法, 方便阅读, 放在此处
    private void setHeadAndPropagate(Node node, int propagate) {
        Node h = head; // Record old head for check below
        // 设置自己为 head
        setHead(node);

        // propagate 表示有共享资源（例如共享读锁或信号量）
        // 原 head waitStatus == Node.SIGNAL 或 Node.PROPAGATE
        // 现在 head waitStatus == Node.SIGNAL 或 Node.PROPAGATE
        if (propagate > 0 || h == null || h.waitStatus < 0 ||
            (h = head) == null || h.waitStatus < 0) {
            Node s = node.next;
            // 如果是最后一个节点或者是等待共享读锁的节点
            if (s == null || s.isShared()) {
                // 进入 ㈡
                doReleaseShared();
            }
        }
    }

    // ㈡ AQS 继承过来的方法, 方便阅读, 放在此处
    private void doReleaseShared() {
        // 如果 head.waitStatus == Node.SIGNAL ==> 0 成功, 下一个节点 unpark
        // 如果 head.waitStatus == 0 ==> Node.PROPAGATE, 为了解决 bug, 见后面分析
        for (;;) {
            Node h = head;
            // 队列还有节点
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue; // loop to recheck cases
                    // 下一个节点 unpark 如果成功获取读锁
                    // 并且下下个节点还是 shared, 继续 doReleaseShared
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue; // loop on failed CAS
            }
            if (h == head) // loop if head changed
                break;
        }
    }
}

读锁释放流程

static final class NonfairSync extends Sync {

    // ReadLock 方法, 方便阅读, 放在此处
    public void unlock() {
        sync.releaseShared(1);
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    public final boolean releaseShared(int arg) {
        if (tryReleaseShared(arg)) {
            doReleaseShared();
            return true;
        }
        return false;
    }

    // Sync 继承过来的方法, 方便阅读, 放在此处
    protected final boolean tryReleaseShared(int unused) {
        // ... 省略不重要的代码
        for (;;) {
            int c = getState();
            int nextc = c - SHARED_UNIT;
            if (compareAndSetState(c, nextc)) {
                // 读锁的计数不会影响其它获取读锁线程, 但会影响其它获取写锁线程
                // 计数为 0 才是真正释放
                return nextc == 0;
            }
        }
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    private void doReleaseShared() {
        // 如果 head.waitStatus == Node.SIGNAL ==> 0 成功, 下一个节点 unpark
        // 如果 head.waitStatus == 0 ==> Node.PROPAGATE 
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                // 如果有其它线程也在释放读锁，那么需要将 waitStatus 先改为 0
                // 防止 unparkSuccessor 被多次执行
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue; // loop to recheck cases
                    unparkSuccessor(h);
                }
                // 如果已经是 0 了，改为 -3，用来解决传播性，见后文信号量 bug 分析
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue; // loop on failed CAS
            }
            if (h == head) // loop if head changed
                break;
        }
    } 
}
3.2 StampedLock

该类自 JDK 8 加入，是为了进一步优化读性能，它的特点是在使用读锁、写锁时都必须配合【戳】使用加解读锁

long stamp = lock.readLock();
lock.unlockRead(stamp);

加解写锁

long stamp = lock.writeLock();
lock.unlockWrite(stamp);

乐观读，StampedLock 支持 tryOptimisticRead() 方法（乐观读），读取完毕后需要做一次 戳校验 如果校验通过，表示这期间确实没有写操作，数据可以安全使用，如果校验没通过，需要重新获取读锁，保证数据安全。

long stamp = lock.tryOptimisticRead();
// 验戳
if(!lock.validate(stamp)){
 // 锁升级
}

提供一个 数据容器类 内部分别使用读锁保护数据的 read() 方法，写锁保护数据的 write() 方法

class DataContainerStamped {
    private int data;
    private final StampedLock lock = new StampedLock();
    
    public DataContainerStamped(int data) {
        this.data = data;
    }
    
    public int read(int readTime) {
        long stamp = lock.tryOptimisticRead();
        log.debug("optimistic read locking...{}", stamp);
        sleep(readTime);
        if (lock.validate(stamp)) {
            log.debug("read finish...{}, data:{}", stamp, data);
            return data;
        }
        // 锁升级 - 读锁
        log.debug("updating to read lock... {}", stamp);
        try {
            stamp = lock.readLock();
            log.debug("read lock {}", stamp);
            sleep(readTime);
            log.debug("read finish...{}, data:{}", stamp, data);
            return data;
        } finally {
            log.debug("read unlock {}", stamp);
            lock.unlockRead(stamp);
        }
    }
    
    public void write(int newData) {
        long stamp = lock.writeLock();
        log.debug("write lock {}", stamp);
        try {
            sleep(2);
            this.data = newData;
        } finally {
            log.debug("write unlock {}", stamp);
            lock.unlockWrite(stamp);
        }
    }
}

测试 读-读 可以优化

public static void main(String[] args) {
    DataContainerStamped dataContainer = new DataContainerStamped(1);
    new Thread(() -> {
        dataContainer.read(1);
    }, "t1").start();
    
    sleep(0.5);
    
    new Thread(() -> {
        dataContainer.read(0);
    }, "t2").start();
}

输出结果，可以看到实际没有加读锁

15:58:50.217 c.DataContainerStamped [t1] - optimistic read locking...256 
15:58:50.717 c.DataContainerStamped [t2] - optimistic read locking...256 
15:58:50.717 c.DataContainerStamped [t2] - read finish...256, data:1 
15:58:51.220 c.DataContainerStamped [t1] - read finish...256, data:1

测试 读-写 时优化读补加读锁

public static void main(String[] args) {
    DataContainerStamped dataContainer = new DataContainerStamped(1);
    new Thread(() -> {
        dataContainer.read(1);
    }, "t1").start();
    
    sleep(0.5);
    
    new Thread(() -> {
        dataContainer.write(100);
    }, "t2").start();
}

输出结果

15:57:00.219 c.DataContainerStamped [t1] - optimistic read locking...256 
15:57:00.717 c.DataContainerStamped [t2] - write lock 384 
15:57:01.225 c.DataContainerStamped [t1] - updating to read lock... 256 
15:57:02.719 c.DataContainerStamped [t2] - write unlock 384 
15:57:02.719 c.DataContainerStamped [t1] - read lock 513 
15:57:03.719 c.DataContainerStamped [t1] - read finish...513, data:1000 
15:57:03.719 c.DataContainerStamped [t1] - read unlock 513

注意

  • StampedLock 不支持条件变量

  • StampedLock 不支持可重入

BirdMan98
关注
专栏目录
JUC高并发编程从入门到精通（全）
码农研究僧的博客
08-06 1万+
目录前言 前言 在了解这部分内容的时候 先要了解java的一些基础内容 java零基础从入门到精通（全） javaSE从入门到精通（全） 所谓JUC是java.util .concurrent 工具包的简称这是一个处理线程的工具包可以实现多线程高并发的内容 了解该部分内容先了解线程与进程的相关概念 【操作系统】线程与进程的深入剖析（全） java之Thread类详细分析（全） 以及涉及到的lambda表达式函数的概念 java中lambda表达式 ......
JUC并发编程（二）--- 并发下集合不安全及解决方案，读写锁，阻塞队列
化身强盗的博客
01-07 840
文章目录6、集合类不安全问题6.1 List不安全1、Vector2、synchronizedList转换3、CopyOnWriteArrayList6.2 Set不安全回顾一下HashSet：1、synchronizedSet转换2、CopyOnWriteArraySet6.3 Map不安全1、HashTable2、ConcurrentHashMap7、常用辅助类7.1 CountDownLatch7.2 CyclicBarrier7.3 Semaphore8、读写锁9、阻塞队列9.1 阻塞队列和非阻塞队
html5实现好看的个人博客模板源码
接受定制，友情互惠，致力于前端的全类型模板，打造通用模板源码，进阶于前后端联合模板，适用于全类型。
01-03 6326
html5实现好看的个人博客模板，个人空间源码，个人主页源码，模板分为，首页、认识我，我的文章，我的模板，文章内容等页面，在此基础上可根据博客模板，扩展更多的功能，统一的风格，代码上手简单，代码独立，可以直接使用。也可直接预览效果。如有代码问题可以私信联系博主，帮忙解决。
【Web 三件套】个人简单博客系统页面搭建（附源码）
吞吞吐吐大魔王的博客
02-20 4万+
文章目录1. 成品展示2. 知识准备3. 博客系统页面搭建3.1 基本介绍3.2 博客列表页3.3 博客详情页3.4 博客登录页3.5 博客编辑页3.6 公共页面样式3.7 markdown 编辑器引入4. 总结 1. 成品展示 以下为个人搭建的一个简单博客系统页面，以后会不断改进，并且与后端结合，形成一个完整的博客系统 2. 知识准备 该博客系统页面是由 HTML + CSS + JavaScript 搭建的，如果没有了解过这些知识的友友，可以通过本人之前写好的几篇相关文章入门 文章一：《超多动图带
分享188个PHP博客系统，总有一款适合您
最新发布
zy0412326的专栏
07-30 801
NDlog(NDesign) 单用户博客系统 php版 v1.2 UTF8 Build130521。AK博客网站 php个人博客系统 v4.2.8 build20121026 UTF8。php博客系统 Simple-Log v1.5 build20111106 v1.5。php 博客系统 WordPress for Linux v3.04 简体中文版。Simple-Log php博客系统 v1.6 build 20120201。记事狗 php博客系统 v3.6.6.20120829 升级包 UTF-8。
分享46个Python博客源代码总有一个是你想要的
zy0412326的专栏
10-30 1389
分享46个Python博客源代码总有一个是你想要的
【博客系统】页面设计（附完整源码）
书生-w的博客
05-12 1万+
目前我们对 HTML ， CSS ， JavaScript 已经有了个简单的了解 ， 但是还不太熟悉 ，下面就通过 写一个博客系统的 网站 (静态网页) 来 熟悉他们 ，等后面 我们学习了 HTTP ， servlet ， Tomcat ， spring 系列框架 就能完成一个前后端交互的小项目 .
精美博客源码
qq_67385923的博客
04-20 2755
这是一个精美的博客源码 原作者找不到了，因为现在跑路了😂 话不多说，上源码 https://qsnb.lanzouq.com/b020llczc 密码:0000 注意：本人非作者，发生一切法律问题不要找我 搭建教程： 1.上传源码至文件管理器 2.绑定域名 3.打开域名，进行安装 ...
java并发编程：juc、aqs
08-09
Java并发编程中的`JUC`(Java Util Concurrency)库是Java平台中用于处理多线程问题的核心工具包，它提供了一系列高效、线程安全的工具类，帮助开发者编写并发应用程序。`AQS`(AbstractQueuedSynchronizer)是JUC库中的...
高级技术之 JUC 高并发编程
wa_ka_ka的博客
08-25 813
1，什么是 JUC 1.1 JUC简介 JUC 就是java.util.concurrent 工具包的简称，这一个专门用来处理线程的工具包，JDK1.5开始出现 1.2 进程与线程 **进程（Process）：**是系统进行资源分配和调度的基本单位，比如QQ启动就是一个进程。 **线程（Thread）：**是操作系统能够进行运算调度的最小单位，是程序执行的最小单位，它被包含在进程中，比如QQ中的各个功能，都是不同的线程。 1.3 线程的状态 在Thread类中枚举了线程的6种状态; pu
深入浅出_Java并发工具包原理讲解
01-29
3. 各种并发工具类：包括闭锁（CountDownLatch）、栅栏（CyclicBarrier）、信号量（Semaphore）、读写锁（ReentrantReadWriteLock）等，这些工具类提供了丰富的线程间协调和控制的机制，使得多线程之间的合作更加...
推荐6个开源博客项目源码，你会选哪个呢
CTZL123456的博客
07-08 1532
基于SpringBoot实现零配置让系统的配置更简单，使用了Mybatis-Plus快速开发框架，在不是复杂的查询操作下，无需写sql就可以快速完成接口编写。本项目，主要宗旨在于，简单、易用、不烧脑的博客，Plumemo，搭建一个属于博主们的博客圈。开源免费的博客系统，使用Java语言开发。Plumemo 是一个轻量、易用、前后端分离的博客系统，为了解除开发人员对后端的束缚，真正做到的一个面向接口开发的博客系统。由于项目是前后端完全分离，所以此项目为单独的后端项目，后台管理系统、博客主题可以进行自由搭配。
SpringBoot个人博客系统(含源码+数据库)
热门推荐
WEN38306482的博客
06-06 18万+
个人博客系统的数据库可以设计如下。这个应用程序的目的是为用户提供一个平台，在该平台上用户可以尽情的表达自己的思想、发布自己的文章、分享自己的生活，同时也可以和朋友互动。(5)留言板功能：个人博客的留言板功能是一个重要的交流平台，让用户可以和其他用户进行信息交流和互动，用户可以在该页面中留下评论、提问、分享自己的看法等等。总之，个人博客系统需要有合理的功能、可扩展的结构、创新的设计、完美的用户体验，并且紧紧贴近用户，这些必须得同步达到，让用户拥有一个方便、快捷、便利、符合人性化的博客使用体验。
搭建一个自己的博客网站（typecho开源博客源码）
weixin_47075747的博客
07-29 1336
配置CDN加速（需要购买，花个几十块钱可以用很久），配置SSL证书，在阿里云的控制台都可以直接完成（前提条件是必须是阿里云购买的服务器才行）。
分享46个ASP.NET博客程序源码，总有一款适合您
zy0412326的专栏
03-05 2058
分享46个ASP.NET博客程序源码，总有一款适合您
个人博客系统(附源码)
qq_774952435的博客
06-09 1万+
准备工作主要就是测试一下环境是否正常,编写一些简单的代码来验证页面是否可以顺利访问!这里主要引入需要用到的各种依赖包: 将这些全部放在dependencies标签里面 在webapp目录下就可以放置所编写好的前端页面了,切记不是放在WEB-INF目录下!!!这里写简单的代码进行测试环境 ...
基于Spring Boot的个人博客系统（源码+数据库）
WHT869706733的博客
11-28 1万+
个人博客系统分为前台管理和后台管理。前台管理的功能有用户登录、文章分页展示、文章详情查看、文章评论。后台管理的功能有用户登录、系统数据展示、文章发布、文章修改、文章删除。
三个美观的个人博客网站源码
dogeven的博客
06-25 1741
介绍：此源码来自互联网，仅供学习研究之用，不提供技术支持，请勿商用或者其他违法用途，产生其他后果与本站无关，如需要请购买正版，如有侵权请联系站长，站长会第一时间处理！支持后台一键快速安装，让开发者能快的实现业务功能开发。ModStart是开源框架，无需授权即可商业使用，代码全部开源免费且无任何加密。管理系统源码破解版，由蓝优破解。网络收集，不确认是否完整或安全，大家自行测试。拥有丰富的开发文档和教程，支持定制开发，所有模块均支持二次开发。支持模块任意搭配的方式进行极速开发，让系统能以最快的速度上线。
个人博客系统源码
m0_73146715的博客
03-15 1167
个人博客系统源码
Java并发编程深度解析：内存模型、锁与JUC框架的应用
本文档围绕Java内存模型、锁机制、JUC并发包以及实际编程实践展开讨论，旨在帮助开发者掌握并发编程的基础理论和实践经验。 首先，Java内存模型（Memory Model）是Java虚拟机(JVM)对内存访问规则的抽象，它确保了多...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

BirdMan98

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值