1.从 ExoPlayer 源码分析视频无法播放问题
2.java.lang.UnsupportedOperationException问题分析及解决
3.Druid之ExceptionSorter源码分析
4.java中 异常类Exception(String message,码解 Throwable cause)
5.exception和error区别
6.七爪源码：Java 中的 NullPointerException 是什么？ 让我们了解并学习如何避免它！

从 ExoPlayer 源码分析视频无法播放问题

       面对项目中出现的码解视频无法播放问题，我们在ExoPlayer三方库中发现了Decoder init failed的码解常见错误，即（ERROR_CODE_DECODER_INIT_FAILED）。码解在Google搜索未果后，码解我们决定深入源码以寻找问题根源。码解源码交付什么意思最终，码解通过源码分析，码解我们找到了问题所在并找到了解决方案，码解希望能为遇到类似问题的码解读者提供帮助。

       对比应用，码解我们发现使用ExoPlayer播放动态壁纸在多个机型上均能正常工作，码解这有助于排除机型因素。码解随后，码解我们引入ExoPlayer库并创建了一个简单的码解Demo，测试对比后发现，虽然在特定机型上可以播放网络视频链接，但无法播放我们的视频链接。这提示我们可能是在视频格式上存在问题。

       在源码分析中，精选指标源码公式我们发现MediaCodecVideoRenderer抛出的ExoPlaybackException是问题的关键。从调用栈关系可以看出，问题最终归咎于MediaCodecRenderer的maybeInitCodecWithFallback()方法。深入源码分析后，我们发现initCodec()方法调用时出现了异常，进一步导致了DecoderInitializationException。异常信息与日志显示一致，我们继续追踪initCodec()的逻辑。

       通过断点调试，我们发现逻辑最终到达了DefaultMediaCodecAdapterFactory的createAdapter()方法，进一步跟进到SynchronousMediaCodecAdapter.Factory中的createAdapter()方法，最终调用了MediaCodec的configure()方法，导致异常。从源码中可以看出，无论逻辑是否执行到特定的if条件，最终都会调用到MediaCodec方法，因此无需关注if逻辑。

       我们意识到最终调用的是C/C++代码，通常在Android端遇到此类异常时似乎无能为力。同花顺精准指标源码然而，我们从另一个角度思考问题，即在能够播放视频的机型和无法播放的机型之间是否存在参数差异。通过逐步回溯排查MediaCodecInfo对象的值，我们最终发现了关键逻辑代码。

       分析后，我们得知首先通过getAvailableCodecInfos()方法获取一组可用解码器列表，然后通过逻辑判断将列表中的所有解码器或第一个添加到队列availableCodecInfos中。接下来，通过while循环不断从availableCodecInfos队列中取出第一个解码器进行初始化尝试，直到找到成功初始化的解码器为止。

       从代码注释中，我们了解到enableDecoderFallback参数的含义，设置为true可能导致性能降低（软解性能不如硬解），但默认情况下优先初始化硬解。通过设置setEnableDecoderFallback(true)，问题得以解决，从而实现了视频的正常播放。

java.lang.UnsupportedOperationException问题分析及解决

       在编写代码过程中，mvc小程序源码遇到了一个令人困惑的报错问题：java.lang.UnsupportedOperationException。这问题源自代码中的一行：psParamList.remove("GPRS=1");那么，为什么会产生这种报错呢？让我们一起来深入分析并解决这个问题。

       报错的源头在于psParamList的remove操作。起初，我们对这一现象感到不解。难道是psParamList不支持remove方法？显然，这与我们的预期不符。随后，我们查阅了Arrays.asList方法的源码，发现返回的ArrayList实际上是Arrays类的静态内部类，即Arrays$ArrayList。而这一类并非java.util.ArrayList。在深入源码后，我们发现Arrays$ArrayList类并未实现remove、add等方法，因此在执行这些操作时，就会触发java.lang.UnsupportedOperationException错误。

       通过以上分析，程序源码怎么查看我们已经找到了问题的根源。为了解决这个问题，我们需要对代码进行相应的调整。具体而言，我们可以将Arrays.asList方法替换为Collections.singletonList或者使用java.util.Arrays的asList方法。这样，我们便可以利用Java集合框架中的ArrayList类，从而实现remove等操作。通过这种方式，不仅解决了java.lang.UnsupportedOperationException错误，同时也保证了代码的正常运行。

Druid之ExceptionSorter源码分析

       ExceptionSorter机制在Druid连接池中扮演着关键角色，用于识别和剔除数据库操作过程中的"不可用连接"。当网络断开或数据库服务器崩溃时，连接池会遇到大量"不可用连接"，而ExceptionSorter机制正是通过异常类型、代码、原因和消息来判断这些连接是否可用，从而保证连接池的稳定性和高效性。

       Druid连接池内置了多种ExceptionSorter，其设计旨在确保在数据库重启或网络中断后，连接池能够自动恢复工作。这使得ExceptionSorter成为判断连接池稳定性的重要指标。

       初始化ExceptionSorter的代码位于DruidAbstractDataSource类的initExceptionSorter方法中。所有具体的ExceptionSorter实现了ExceptionSorter接口，该接口包含两个方法。这些方法的实现决定了ExceptionSorter如何根据特定的异常信息进行连接的处理。

       在Druid中的使用场景主要是在数据库操作异常时，调用DruidPooledConnection类的handleException方法。当数据库操作出现异常，处理逻辑首先会判断该异常是否为致命性错误，即是否满足isExceptionFatal方法的返回条件。

       以MySQL为例，isExceptionFatal方法的实现逻辑通常会根据异常的具体类型和错误代码来判断。当判定为致命性错误时，Druid会调用discardConnection方法关闭当前连接。这一过程有效地剔除了"不可用连接"，确保了连接池的健康状态。

       综上所述，Druid通过ExceptionSorter机制实现了对"不可用连接"的高效识别与剔除，从而确保了数据库操作的稳定性和连接池的高效管理。关键在于isExceptionFatal方法的判断逻辑和discardConnection方法的执行，二者共同作用，使得连接池能够在异常情况下自动恢复，提供持续、稳定的数据库服务。

java中 异常类Exception(String message, Throwable cause)

       æ˜¯å¼•èµ·è¿™ä¸ªå¼‚常的异常，如果这个值是空值，那么这个异常就是源头；如果这个值等于自己，那么这个异常还没被初始化。

       ä¸‹é¢æ˜¯JDK中源码给出的注释，英语好的话一看就懂。

        /

        * The throwable that caused this throwable to get thrown, or null if this

        * throwable was not caused by another throwable, or if the causative

        * throwable is unknown. If this field is equal to this throwable itself,

        * it indicates that the cause of this throwable has not yet been

        * initialized.

        * @serial

        * @since 1.4

        */

exception和error区别

       以java为例，其exception和error的区别如下：

       1、Exception和Error都继承了Throwable类，在java中只有Throwable类型的实例才可以被抛出（Throw）或者捕捉（catch），它是异常处理机制的基本组成类型。Exception是程序正常运行中，可以预料的意外情况，可能并且应该被捕获，进行相应的处理。

       2、Error指在正常情况下，不大可能出现的情况，绝大部门的Error都会导致程序处于非正常的，不可恢复状态。既然是非正常情况，所以不便于也不需要捕获。比如常见的OutOfMemoryError之类，都是Error的子类。

       Exception类又分为可检查异常（checked）和不检查异常（unchecked），可检查异常在源码里必须显示的进行捕获处理，这是编译期检查的一部分。不检查异常就是所谓的运行时异常，类似NullPointerException，ArrayIndexOutOfBoundsException之类，通常是可以编码避免的逻辑错误。

七爪源码：Java 中的 NullPointerException 是什么？ 让我们了解并学习如何避免它！

       在 Java 编程中，一个常见的陷阱是 NullPointerException，它会在试图使用一个未初始化或已被赋值为 null 的对象时引发。本文将深入探讨这个错误，提供实例并揭示其背后的机制。

       NullPointerException 指的是当我们试图调用一个 null 引用的方法或访问其字段时，程序会抛出异常。这就好比试图访问一个尚未存在的内存位置。简单来说，当声明一个变量却没有为其分配实际对象，即没有初始化，然后试图使用该变量时，就会引发这样的错误。

       让我们通过一个实例来理解。考虑以下代码，myString 变量被赋予 null 值：

       尝试运行这段代码会抛出错误，因为尝试调用一个不存在的对象的 length 方法。程序找不到给定引用的对象，所以该操作无效。

       为了避免这种情况，确保在使用变量前先进行初始化，如：

       这样，myString 引用就会指向一个实际存在的字符串对象，避免了 NullPointerException。

       我们还可以看到，即使在自定义类中，如 Point 类，如果在调用方法前没有正确实例化，也会遇到类似问题。比如，尝试调用一个未初始化的 Point 对象的 toString 方法：

       在编写代码时，通过良好的错误处理和避免空值，可以显著减少这类错误。使用 Option 或 Either 类型的结构可以帮助处理可能的空值情况，但在实际应用中，调试工具（如 Debug）仍然是查找和修复 null 错误的最佳途径。

       希望本文解答了 Java NullPointerException 的问题。持续关注我们的资源，以获取更多编程技巧和最佳实践。