2023-09-13
原文作者:https://blog.csdn.net/wangwei19871103/category_9681495_2.html 原文地址: https://blog.csdn.net/wangwei19871103/article/details/104702301

sysn同步

上次说了异步监听回调,这次我们试试同步看看会怎么样。我在处理器里这么做:

202309132210322621.png

DefaultChannelPromise的sync

202309132210329422.png

DefaultPromise的sync

202309132210340183.png

DefaultChannelPromise的await

202309132210346174.png

DefaultPromise的await

会先检查是否完成,完成了就不需要等了,然后看是否有中断,再检查死锁,最后再判断是否完成,没完成就进行wait,等待通知唤醒,唤醒了后还是要继续循环看是否完成了,只有完成了才可以返回。现在我们知道同步原理是内部用了一个无限循环来判断是否是否完成,如果完成了才会返回,否则就一直wait

      @Override
        public Promise<V> await() throws InterruptedException {
            if (isDone()) {
                return this;
            }
    
            if (Thread.interrupted()) {
                throw new InterruptedException(toString());
            }
    
            checkDeadLock();
    
            synchronized (this) {
                while (!isDone()) {
                    incWaiters();
                    try {
                        wait();
                    } finally {
                        decWaiters();
                    }
                }
            }
            return this;
        }

DefaultPromise的incWaiters

这个就是如果wait前会增加等待的记录。

202309132210351485.png
这东西干嘛用呢,就是我们前面说的,在通知前,会checkNotifyWaiters判断:

202309132210361726.png

202309132210371097.png
如果有等着的,就需要唤醒notifyAll所有的,因为完成了嘛,这样wait的才可以返回,不阻塞了。

DefaultChannelPromise的checkDeadLock

我们来看下检查死锁:

      @Override
        protected void checkDeadLock() {
            if (channel().isRegistered()) {
                super.checkDeadLock();
            }
        }
DefaultPromise的checkDeadLock

具体会看是不是当前线程是不是DefaultPromise的执行器的线程是IO线程,如果是IO线程,当然报阻塞IO线程的异常啦。

    protected void checkDeadLock() {
            EventExecutor e = executor();
            if (e != null && e.inEventLoop()) {
                throw new BlockingOperationException(toString());
            }
        }

看看不报异常的情况,就是我们主线程在bind后的同步阻塞,因为调用这个方法的当前线程是主线程,不是事件循环的IO线程,所以不会报死锁的异常:

202309132210375168.png

cancel取消

我们再来研究下取消的情况:

202309132210395769.png

DefaultPromise的cancel

会设置一个取消异常,然后直接通知监听器,传进来的参数貌似用:

2023091322104025610.png

tryFailure失败

我们来看下设置失败是怎么样的,失败必须要传入一个异常。

2023091322104098911.png

DefaultPromise的tryFailure

2023091322104229312.png

DefaultPromise的tryFailure0

会封装成一个CauseHolder

2023091322104310013.png
然后是设置:

2023091322104363914.png
最后到了回调里面:

2023091322104552515.png

DefaultPromise的其他方法

isCancelled

2023091322104624516.png

isCancelled0

需要有异常持有CauseHolder,且里面异常类型是CancellationException才算是取消,否则可能只是其他的失败异常。

2023091322104767217.png
其他的一些也都差不多,理解这些基本的其他没啥问题的。

DefaultProgressivePromise写进度的回调

可以写进度的回调,拿个简单的例子:

      DefaultProgressivePromise<Void> voidDefaultProgressivePromise = new DefaultProgressivePromise<>(ctx.executor());
            voidDefaultProgressivePromise.addListener(new GenericProgressiveFutureListener(){
    
                @Override
                public void operationComplete(Future future) throws Exception {
                    System.out.println("operationComplete");
                }
    
                @Override
                public void operationProgressed(ProgressiveFuture future, long progress, long total) throws Exception {
                    System.out.println("progress:"+progress+" total:"+total);
                }
            });
            voidDefaultProgressivePromise.tryProgress(1,100);
            voidDefaultProgressivePromise.tryProgress(10,100);
            voidDefaultProgressivePromise.setProgress(100,100);
            voidDefaultProgressivePromise.setSuccess(null);

结果:

2023091322104883418.png
其实内部逻辑跟前面差不多,我就不解释了,贴个流程吧:

2023091322104949719.png

2023091322105006020.png

2023091322105102921.png

2023091322105217022.png
其实他不会去计算进度,你传什么,他就给你传回去,所以得在外面计算好进度,然后回调回去。

好了,今天就到这里了,希望对学习理解有帮助,大神看见勿喷,仅为自己的学习理解,能力有限,请多包涵。

阅读全文