1.解析Stream foreach源码
2.于——InputStream类源码详解
3.FFmpeg源码分析: AVStream码流
4.零基础读懂视频播放器控制原理： ffplay 播放器源代码分析
5.Java Stream流与Optional流浅析
6.每日一例 | 更优雅地关闭流（Stream）

解析Stream foreach源码

       本文深入解析Stream的源码foreach操作源码，主要关注串行流和并行流的源码区别，特别是源码并行流背后的ForkJoin框架。

       在Stream中，源码操作可分为中间操作和结束操作，源码其中foreach属于结束操作。源码IP核源码解密串行流与并行流的源码主要区别在于实现方式，串行流是源码线性执行，而并行流则利用了ForkJoin框架的源码分治策略。

       对于串行流（如`stream`），源码其执行过程如下：

       获取ReferencePipeline.Head的源码Stream实现，内部包含ArrayListSpliterator对象。源码

       通过ArrayListSpliterator的源码forEachRemaining方法逐一执行元素操作。

       而并行流（如`parallelStream`）则更为复杂：

       同样获取ReferencePipeline.Head的源码Stream实现，内部有ArrayListSpliterator。源码

       调用父类的forEach方法，构建一个ForEachTask。

       在ForEachTask的invoke方法中，调用compute方法，利用ForkJoin框架的分治策略将任务拆分到commonPool中的线程池执行。

       子任务通过拆分器的forEachRemaining方法，最终执行用户定义的action.accept(e)回调。

       ForkJoin框架是JDK7新增的，它通过线程池执行任务，尤其适用于并行处理。在并行流中，任务会分配到Java 8中预定义的commonPool，该线程池基于计算机处理器数量进行配置，以实现高效的并行计算。

于——InputStream类源码详解

       InputStream类是字节输入流的基础，它作为所有字节输入流类的超类，提供了读取字节的基本功能。

       从InputStream读取下一个数据字节时，返回的值位于0到的整数范围内，代表字节值。若流已到达末尾而无更多字节，会返回值-1。在获取数据、遇到流终点或抛出异常之前，此方法始终处于阻塞状态。

       实现InputStream接口的子类通常会根据具体的应用场景，扩展或修改InputStream的基础行为。例如，FileInputStream用于从文件读取字节，发红包源码而ByteArrayInputStream用于从字节数组读取。

       InputStream类提供了基础的读取操作，包括read()方法用于读取单个字节，read(byte[] b)方法用于读取多个字节到字节数组中，以及read(byte[] b, int off, int len)方法用于指定读取字节的位置和数量。这些方法共同构成InputStream类的核心功能。

       通过使用InputStream类及其子类，开发者可以实现从文件、网络连接、设备输入或其他数据源的字节读取，为数据处理、文件操作和网络通信等提供了基础支持。

       在实际应用中，开发者需谨慎处理异常情况，比如文件未找到、网络连接断开或读取操作超时等，并合理使用非阻塞读取机制，以提高程序的性能和响应速度。

       总之，InputStream类作为字节输入流的基础，为各种应用场景提供了灵活和高效的数据读取能力。深入理解其内部机制和用法，对于开发高效、可靠的软件系统至关重要。

FFmpeg源码分析: AVStream码流

       在AVCodecContext结构体中，AVStream数组存储着所有视频、音频和字幕流的信息。每个码流包含时间基、时长、索引数组、编解码器参数、dts和元数据。索引数组用于保存帧数据包的offset、size、timestamp和flag，方便进行seek定位。

       让我们通过ffprobe查看mp4文件的码流信息。该文件包含5个码流，是双音轨双字幕文件。第一个是video，编码为h，帧率为.fps，分辨率为x，全民vip解析源码像素格式为yuvp。第二个和第三个都是audio，编码为aac，采样率为，立体声，语言分别为印地语和英语。第四个和第五个都是subtitle，语言为英语，编码器为mov_text和mov_text。

       调试实时数据显示，stream数组包含以下信息：codec_type（媒体类型）、codec_id、bit_rate、profile、level、width、height、sample_rate、channels等编解码器参数。

       我们关注AVCodecContext的编解码器参数，例如codec_type、codec_id、bit_rate、profile、level、width、height、sample_rate和channels。具体参数如下：codec_type - 视频/音频/字幕；codec_id - 编码器ID；bit_rate - 位率；profile - 编码器配置文件；level - 编码器级别；width - 宽度；height - 高度；sample_rate - 采样率；channels - 音道数。

       AVStream内部的nb_index_entries（索引数组长度）和index_entries（索引数组）记录着offset、size、timestamp、flags和min_distance信息。在seek操作中，通过二分查找timestamp数组来定位指定时间戳对应的帧。seek模式有previous、next、nearest，通常使用previous模式向前查找。

       时间基time_base在ffmpeg中用于计算时间戳。在rational.h中，AVRational结构体定义为一个有理数，用于时间计算。天津防伪溯源码要将时间戳转换为真实时间，只需将num分子除以den分母。

零基础读懂视频播放器控制原理： ffplay 播放器源代码分析

       视频播放器的核心原理在于控制音视频帧序列，其中ffplay作为FFmpeg自带的播放器，利用ffmpeg解码库和sdl库进行视频渲染。本文将通过分析ffplay源代码，深入解析音视频同步、播放控制的原理。

       FFmpeg的跨平台特性使得在PC端分析代码更为高效，本文则主要聚焦于ffplay for MFC的移植代码。首先，理解视频文件结构，每个MP4文件包含封装格式、比特率等信息，音视频被区分为独立的stream，并有各自的参数。解复用后，音频和视频帧转化为原始数据，进入播放流程，如图2所示。

       简化播放器，仅考虑视频解码和SDL显示，其流程图显示了FFmpeg初始化、读取并解码帧、然后渲染到窗口的过程。为了实现音视频同步，播放器需要处理帧率、音频采样率和视频帧显示时间的关系，以及不同流的帧数差异。

       文章接下来提出五个关键问题，涉及画面、字幕和声音的组合，音视频同步的具体机制，以及快进/后退操作的实现。ffplay通过定义VideoState结构体，将播放控制分发到不同线程，利用PTS时间戳确保音视频同步。视频播放器操作的实现包括控制暂停和播放，以及通过时间而非帧数进行快进/后退，以保持同步。

       分析ffplay代码时，整体结构包括定时器刷新、多线程解码和显示，linux 0.11 ls源码以及关键控制函数的使用。在深入理解PTS和DTS后，我们看到ffplay如何动态调整PTS以实现音视频同步。最后，文章总结了通过ffplay源码学习到的基础概念和实用技巧，强调了从基础开始理解、代码架构分析和平台选择的重要性。

Java Stream流与Optional流浅析

       Stream流

       1. 操作类型

       Stream API中的操作类型主要分为两大类：中间操作和终止操作。中间操作仅作为标记，实际计算会在触发终止操作时进行。

       2. Stream的操作过程

       首先，我们准备了一些示例代码。在TestStream类中，我们定义了一些测试lambda函数的方法。在main方法中，我们执行了一个相关的流操作，在控制台中并没有看到任何输出。这说明Stream并没有真正执行到对应的方法中，因为我们没有写入终止操作。由此可见，在终止操作之前，Stream并没有真正去执行每个中间操作，而是将中间操作记录了下来。在执行终止操作这一行代码时，再去执行中间操作。

       2.1 记录过程

       进入源码后，可以看到Collection的Stream方法调用了StreamSupport.stream()方法。在该方法中，返回了一个ReferencePipeline.Head对象，这是记录管道操作的头节点对象。这个Head对象继承了ReferencePipeline对象，所以后续的map、filter等方法实际上是ReferencePipeline对象的方法。在构造方法中，也调用了父类AbstractPipeline类的构造方法。

       在Stream中，每一步操作都被定义为一个Stage。在构造方法中，定义了previousStage和sourceStage，即上一个节点和头节点。在类中还有一个nextStage对象。

       Stream实际上构建了一个双向链表来记录每一步操作。接下来，我们看一下list.map()方法。

       在该方法中，创建了一个StatelessOp对象，它代表无状态的中间操作。这个对象同样继承了ReferencePipeline。在该对象的构造方法中，将调用该初始化方法的节点定义为上一个节点，并且对应的深度depth也进行了+1操作。

       我们总结一下，stream()方法得到的是HeadStage，之后每一个操作（Operation）都会创建一个新的Stage，并以双向链表的形式结合在一起。每个Stage都记录了本身的操作。Stream就以此方式实现了对操作的记录。注意，结束操作不算depth的深度，它也不属于stage。但是我们的示例语句中没有写结束操作的代码，所以在这里提一下Stream的Lazy机制。它的特点是：Stream直到调用终止操作时才会开始计算，没有终止操作的Stream将是一个静默的无操作指令。

       Stage相关类如下

       2.2 执行过程

       在了解执行过程之前，我们应该先了解另一个接口Sink，它继承了Consumer接口。在调用map、filter等无状态操作中返回的StatelessOp对象中，覆盖了opWrapSink方法，返回了一个Sink对象，并且将参数中的Sink对象作为构造方法中的参数传入进去。

       走进构造方法后，可以看到在该对象中定义了一个downstream，该对象也是一个Sink类型的对象，并且在定义Sink对象时，覆盖了Consumer接口中的accept方法。

       不难看出，在执行accept方法时，就是将当前节点的操作结果传入给downstream继续执行，而这个downstream则是通过onWrapSink方法中传入过来的。

       了解了以上这些概念，我们可以走进结束操作.collect(Collectors.toList());方法。在该方法中，通过Collectors定义了一个另一个ArrayList收集器，并且传入了collect方法中。

       我们暂时只看非并行的部分。在这一行通过ReduceOps定义了一个ReduceOp对象。

       在makeRef方法中，返回了一个ReduceOp对象，该对象覆盖了makeSink()方法，返回了一个ReducingSink对象。我们继续往下走，走进evaluate方法中。

       可以看出，wrapsink方法中，是查找链表的头节点，并且调用每个节点的onWrapSink方法，在该方法中传入当前节点的sink对象，并且将传入的对象定义成自己的下游，形成一个从头节点到尾部节点的Sink单向链表。

       在wrapSink中，通过一层层的前置包装，返回头节点的Sink类传入copyInto方法中。

       在该方法中，先调用了wrappedSink.begin()方法，该方法默认实现为调用downstream的begin方法。相当于触发全部Sink的begin方法，做好运行前的准备。

       具体循环的执行则是在spliterator.forEachRemaining(wrappedSink);方法中，操作如下

       在forEachRemaining方法中，调用了accept方法，也就是在定义onWrapSink方法中初始化Sink对象后定义的accept方法，将自己的执行结果传入downstream继续执行，也就是说，在调用结束操作后才实际执行每个方法。在实际执行过后，在执行end方法进行结束操作。Stream整体的流操作大概就是如此。了解了大概过程后可以找一些常用的case来分析一下。

       2.3 具体分析

       一般情况下都会选择list作为排序容器，大部分情况下都是不知道容器大小的，于是采用RefSortingSink类作为当前节点处理类，该类代码如下。

       可以看到该Sink中的accept方法中，并没有执行下游的accept方法，而是将所有的数据装入了一个ArrayList，在end方法利用arrayList进行排序，并且继续开启后续的循环操作。

       3. 代码建议

每日一例 | 更优雅地关闭流（Stream）

       在日常编程中，流（Stream）的应用极为广泛，如InputStream/OutPutStream、FileInputStream/FileOutPutStream等。你是否习惯于像下面这样关闭流，或者干脆不进行关闭操作？本文将深入探讨流关闭问题，提供更优雅的解决方案。

       通常的关闭方式

       让我们先看一段代码示例：

       不符合代码质量规范

       从逻辑角度看，这似乎是可以接受的，然而，从代码质量和规范性上，它并不达标。使用如sonar或sonarLint插件扫描代码时，会提示存在“Code smell”，推荐采用改进方式。

       try-with-resources方式

       优化后的代码如下所示：

       区别

       优化后的代码相较于原始版本更为简洁，主要变化在于将需要在try代码块中使用的资源放于try()中。这种做法实质上是一种语法优化，简化了资源关闭过程，编译器会在编译时自动处理关闭操作，避免了手动关闭资源的繁琐。下面通过反编译代码进一步解析这一变化。

       发现新大陆

       尽管优化已到位，但为了探究本质差异，我们在close()方法上设置了断点，以观察在不手动关闭资源的情况下，资源是否仍能被自动关闭。

       实验结果

       首先采用try-with-resources方式，发现close方法确实被调用，符合预期。接着，尝试传统写法，同样观察到close方法被调用。然而，更令人好奇的是，在不手动关闭资源的情况下，close方法也成功被调用两次。进一步观察发现，传统写法中，资源在调用close方法后，接着执行了finally块中的关闭操作。

       深入分析

       在查看FileInputStream的源码时，我们发现创建流时，会将其加入到FileDescriptor中。FileDescriptor中的closeAll方法会循环关闭加入其中的流。然而，这一方法在FileInputStream的close方法中被调用，解释了资源的自动关闭机制。

       疑惑与解答

       有人疑惑资源是否在非正常情况下不会自动关闭，但实验显示，即使在异常情况下，资源仍会被正确关闭。至于是否是软件自动完成了关闭操作，答案是否定的，进一步调查证实，这与所使用的JDK版本无关。最终，我们认识到，资源的自动关闭与JDK的try-with-resources语句优化密切相关。

       总结

       本文详细解析了流关闭问题，介绍了优化资源管理的try-with-resources方法，并揭示了资源自动关闭背后的机制。通过深入分析与实验，我们对资源关闭有了更深入的理解，为日常编程提供了更优雅、高效的方法。

使用JDK8 Stream空指针问题分析

       在使用JDK8 Stream API进行集合操作转换时，虽然它极大地方便了代码编写，但也容易引发一些问题。本文将总结一些我们在开发中遇到的常见问题以及解决策略。

       首先，让我们来关注Collectors.toList 存在null值的问题。在处理Stream流时，可能不经意间将null值添加至List对象中。尽管List允许null值存在，但在进行循环遍历时，null值可能导致空指针异常。为了避免这种情况，建议在使用Collectors.toList前，先通过filter方法剔除null值。

       紧接着，我们来看看Collectors.toMap出现NullPointerException的情况。通常，HashMap允许key和value为null，但在Stream API处理时，如果value为null，则会触发空指针异常。分析源码，发现在合并操作中，如果value为null，会抛出空指针异常。为避免此问题，可以在调用toMap之前，使用filter方法去除可能存在的null值。

       另外，使用Collectors.toMap时，还需注意可能出现的Duplicate key问题。虽然源码中的处理逻辑在检测到重复key时会抛出异常，但我们可以自定义mergeFunction参数，以便在处理重复key时实现特定逻辑，如取第一个value或最后一个value，以此覆盖或保留前一个值。

       在使用parallelStream时，重要的一点是它不保证集合顺序。这意味着，当使用parallelStream进行并行执行时，结果的顺序可能与预期不同。若需要保持顺序，可以调用parallelStream().forEachOrdered()方法。

       此外，parallelStream还可能引发线程安全问题。在并行执行时，多线程并发操作可能导致数据不一致。处理这一问题，一种方法是确保parallelStream().forEach()逻辑内的线程安全，另一种方法是将集合转换为并发集合，如使用ConcurrentHashMap或使用Guava库中的并发集合。

       通过上述分析，我们可以更好地理解和管理使用JDK8 Stream API时可能出现的问题，确保代码的稳定性和可靠性。