1.MarkWord和Synchronized的码解锁升级机制详解（JDK8）
2.Open Hardware Monitor好不好
3.Autoware.universe 源码解读（一）
4.直接调节风扇转速的Windows开源工具--Open Hardware Monitor
5.OBS 源码分析- 采集方案之二（显示器采集）
6.源码分析： Java中锁的种类与特性详解

MarkWord和Synchronized的锁升级机制详解（JDK8）

       锁升级机制在JDK 后已经废弃，本文所述仅为面试中常问的码解低版本synchronized的锁升级机制，具体新机制需查阅最新JDK源码。码解

       在Java并发编程中，码解synchronized是码解最常用的关键字，用于保护代码块和方法在多线程场景下的码解wxg源码并发安全问题。synchronized锁基于对象实现，码解通常用于修饰同步方法和同步代码块。码解

       下面给出一段简单的码解Java代码，包含三种synchronized的码解使用方法，通过反编译查看字节码，码解了解synchronized的码解实现原理。

       修饰方法时，码解synchronized关键字会在方法的码解字节码中添加ACC_SYNCHRONIZED标志，确保只有一个线程可以同时执行该方法。码解synchronized修饰静态方法同样添加此标志。

       修饰代码块时，synchronized关键字会在相应的指令区间添加monitorenter和monitorexit指令，JVM通过这两个指令保证多线程状态下的同步。

       ACC_SYNCHRONIZED、monitorenter、monitorexit的解释，来源于官网介绍和chatgpt翻译。

       方法级的synchronized隐式执行，通过ACC_SYNCHRONIZED标志区分，方法调用指令会检查此标志。调用设置ACC_SYNCHRONIZED的方法时，线程进入monitor，执行方法，并在方法调用正常完成或异常中断时退出monitor。

       monitorenter指令尝试获取与对象相关联的monitor的所有权，monitorexit指令执行时，对象相关联的monitor的进入计数减1。

       Monitor是Java中用于实现线程同步和互斥的机制，每个Java对象都与一个Monitor相关联，打赏家族源码主要目的是确保在任何给定时间，只有一个线程能够执行与特定对象相关联的临界区代码。

       ObjectMonitor是JDK 的HotSpot源码中定义的Monitor，其核心参数包括EntrySet、WaitSet和一个线程的owner。

       Java对象与monitor关联，需要了解Java对象布局和对象头的相关知识。

       在JDK 1.6之前，synchronized需要依赖于底层操作系统的Mutex Lock实现，导致效率低下。在JDK 1.6之后，引入了偏向锁与轻量锁来减小获取和释放锁的性能消耗。

       锁升级分为四种状态：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁，锁会随着线程的竞争情况逐渐升级，但锁升级是不可逆的。

       偏向锁在没有其他线程竞争时，持有偏向锁的线程不会主动释放，偏向锁的释放时机是在其他线程竞争该锁时。

       轻量级锁使用CAS操作，尝试将对象头部的锁记录指针替换为指向线程栈上的锁记录。轻量级锁的撤销意味着不再通过自旋的方式等待获取锁，而是直接阻塞线程。

       重量级锁状态下，对象的头部会指向一个Monitor对象，该Monitor对象负责管理锁的获取和释放。

       JDK 1.6及之后版本引入了自适应自旋锁、锁消除和锁粗化等锁优化策略，以进一步提升synchronized的性能。

       自适应自旋锁根据前一次在相同锁上的自旋时间以及锁的持有者状态来动态决定自旋的上限次数。

       锁消除是JVM在JIT编译期间进行的优化，通过逃逸分析来消除不可能存在共享资源竞争的锁。

       锁粗化是通过将加锁范围扩展到整个操作序列的外部，降低加锁解锁的频率来减少性能损耗。

       本文总结了JDK8中synchronized的maven插件源码阅读锁升级机制，介绍了无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁的升级流程，以提升并发效率。

Open Hardware Monitor好不好

       Open Hardware Monitor就是这么一款开放源代码的免费的硬件监控软件，目前最新的版本为0.4 Beta，尽管并非刚刚发布，不过我们觉得还是有介绍给大家的意义，有需求的朋友可以下载留存。

       Open Hardware Monitor可以支持大部分常见的主板芯片与硬件组件，监控包含主板、CPU、硬盘、显示卡、装置的电压、温度、风扇转速与运作频率、即时负载等信息。

       é™¤äº†åœ¨ä¸»è§†çª—中显示各个主要硬件的监控资讯之外，Open Hardware Monitor还提供了一个显示温度变化的即时图表。如果你有需要一直监控着温度或CPU、GPU 的即时动态，也可以开启桌面“Gadget”小工具，直接在桌面上显示最新监控信息与硬件运行状态。

       ä½œä¸ºä¸€æ¬¾å¼€æºè½¯ä»¶ï¼ŒOpen Hardware Monitor除了提供对和位Windows XP/Vista/7系统的支持，还对x平台的Linux系统也提供了支持。

Autoware.universe 源码解读（一）

       在Autoware的自动驾驶仿真软件中，launch文件起着至关重要的作用。autoware.launch.xml是其中一个基础的launch文件，它使用XML语言编写，以定义启动ROS节点、参数和设置默认值。这个文件的核心结构包括version="1.0"（XML 1.0版本）和encoding="UTF-8"（UTF-8编码）。

       文件的前半部分侧重于参数定义和设置，包括地图路径、车辆模型、传感器模型和点云容器，这些都可以通过传递参数进行灵活调整。例如，vehicle_id和launch_vehicle_interface是两个全局参数，vehicle_id默认值为环境变量VEHICLE_ID的值，而launch_vehicle_interface默认为true，表示是否启动车辆接口。

       参数check_external_emergency_heartbeat控制外部紧急停车功能，当不需要时需将其设为false。system_run_mode和launch_system_monitor等参数分别定义了系统的运行模式和是否启动系统监视器。此外，rviz可视化工具的启用、rviz配置文件路径，以及感知模式的选择等也被详细定义。

       launch文件中还包括一个include标签，引入了global_params.launch.py，该文件通过arg标签传递参数，以进行更精细的配置。例如，如果launch_vehicle设置为true，它将启动vehicle.launch.xml，并传递参数。国密工具源码

       总的来说，autoware.launch.xml通过巧妙地定义和传递参数，灵活地控制和配置Autoware的各个子系统，以实现自动驾驶的模拟和测试。

直接调节风扇转速的Windows开源工具--Open Hardware Monitor

       Open Hardware Monitor 是一款功能丰富的开源工具，它不仅具备传统系统温度、电压、风扇转速等监控项目，还能实现风扇转速的直接调节与远程监控，以及显示 Gadget。其开源特性深受关注。最近一次更新为年3月1日，先前曾有接近4年的断更期。

       在Open Hardware Monitor中，控制风扇操作直观明了。只需在“风扇”下找到“控制”选项，通过右键操作即可手动设定风扇转速。对于硬件监控有较高需求的用户而言，使用此软件进行实时监控变得极为便捷。

       作为一款免费且开源的软件，Open Hardware Monitor 具备监控电脑上温度传感器、风扇速度、电压、负载和时钟速度的功能。它广泛支持市面上的硬件监控芯片，通过读取 Intel 和 AMD 处理器的核心温度传感器，能有效监测 CPU 温度。同时，软件还能显示 ATI 和 Nvidia 显卡的温度传感器及 SMART 硬盘的温度。

       兼容性方面，Open Hardware Monitor 支持 Windows XP/Vista/7/8/8.1/及部分 x 架构的 Linux 操作系统，无需安装即可使用。用户可通过其官网或 GitHub 获取源代码进行下载与使用。

       总之，Excel网页版源码Open Hardware Monitor 以其全面的功能、免费与开源的特性，以及对多种硬件监控芯片的支持，成为一款值得推荐的系统监控工具。

OBS 源码分析- 采集方案之二（显示器采集）

       OBS的视频录制功能支持多种采集方式，其中在plugin-main.c文件中定义了不同采集方式的结构体，并通过extern声明。在Windows系统中，特别是从Windows 8开始，显示器采集方式有所改变，以提高采集效率。Windows 8引入了Microsoft DirectX图形基础设施(DXGI)的API，旨在简化桌面协作和远程桌面访问，这一变化使得应用程序能够更轻松地访问和传输桌面内容。

       Windows 8及更高版本的桌面采集API，称为桌面复制API，通过位图和关联的元数据进行优化，允许应用程序请求访问沿监视器边界的桌面内容。API提供的元数据包括脏区域、屏幕移动、鼠标光标信息等，应用程序可以根据这些信息进行优化，如基于脏区域进行处理、硬件加速移动和鼠标数据、以及压缩等。OBS的桌面复制功能主要在duplicator-monitor-capture.c、monitor-capture.c以及libobs-d3d中实现，使用DXGI技术来获取屏幕数据，相比传统GDI截图技术有显著性能提升。

       在添加采集源时，选择使用DXGI技术可以解决fps采集的挑战，特别是对于Windows 8以上的系统。例如，在duplicator-monitor-capture.c中的duplicator_capture_tick方法会根据系统版本决定采用WCG还是DXGI。在使用DXGI时，关键函数如gs_duplicator_update_frame会被频繁调用，获取桌面资源，并可能遇到如DXGI_ERROR_WAIT_TIMEOUT的返回值处理问题。获取到纹理数据后，需要进行拷贝操作。

       DXGI的开发基于COM技术，如果不熟悉这部分，理解相关代码可能会有难度。但熟悉COM的开发者会注意到，如IDXGIOutputDuplication这样的对象都继承自IUnknown。在使用OBS SDK进行二次开发时，确保包含libobs-winrt生成的DLL文件是至关重要的。

源码分析： Java中锁的种类与特性详解

       在Java中存在多种锁，包括ReentrantLock、Synchronized等，它们根据特性与使用场景可划分为多种类型，如乐观锁与悲观锁、可重入锁与不可重入锁等。本文将结合源码深入分析这些锁的设计思想与应用场景。

       锁存在的意义在于保护资源，防止多线程访问同步资源时出现预期之外的错误。举例来说，当张三操作同一张银行卡进行转账，如果银行不锁定账户余额，可能会导致两笔转账同时成功，违背用户意图。因此，在多线程环境下，锁机制是必要的。

       乐观锁认为访问资源时不会立即加锁，仅在获取失败时重试，通常适用于竞争频率不高的场景。乐观锁可能影响系统性能，故在竞争激烈的场景下不建议使用。Java中的乐观锁实现方式多基于CAS（比较并交换）操作，如AQS的锁、ReentrantLock、CountDownLatch、Semaphore等。CAS类实现不能完全保证线程安全，使用时需注意版本号管理等潜在问题。

       悲观锁则始终在访问同步资源前加锁，确保无其他线程干预。ReentrantLock、Synchronized等都是典型的悲观锁实现。

       自旋锁与自适应自旋锁是另一种锁机制。自旋锁在获取锁失败时采用循环等待策略，避免阻塞线程。自适应自旋锁则根据前一次自旋结果动态调整等待时间，提高效率。

       无锁、偏向锁、轻量级锁与重量级锁是Synchronized的锁状态，从无锁到重量级锁，锁的竞争程度与性能逐渐增加。Java对象头包含了Mark Word与Klass Pointer，Mark Word存储对象状态信息，而Klass Pointer指向类元数据。

       Monitor是实现线程同步的关键，与底层操作系统的Mutex Lock相互依赖。Synchronized通过Monitor实现，其效率在JDK 6前较低，但JDK 6引入了偏向锁与轻量级锁优化性能。

       公平锁与非公平锁决定了锁的分配顺序。公平锁遵循申请顺序，非公平锁则允许插队，提高锁获取效率。

       可重入锁允许线程在获取锁的同一节点多次获取锁，而不可重入锁不允许。共享锁与独占锁是另一种锁分类，前者允许多个线程共享资源，后者则确保资源的独占性。

       本文通过源码分析，详细介绍了Java锁的种类与特性，以及它们在不同场景下的应用。了解这些机制对于多线程编程至关重要。此外，还有多种机制如volatile关键字、原子类以及线程安全的集合类等，需要根据具体场景逐步掌握。

找到卡顿来源，BlockCanary源码精简分析

       通过屏幕渲染机制我们了解到，Android的屏幕渲染是通过vsync实现的。软件层将数据计算好后，放入缓冲区，硬件层从缓冲区读取数据绘制到屏幕上，渲染周期是ms，这让我们看到不断变化的画面。如果计算时间超过ms，就会出现卡顿现象，这通常发生在软件层，而不是硬件层。卡顿发生的原因在于软件层的计算时间需要小于ms，而计算的执行地点则在Handler中，具体来说是在UI的Handler中。Android进程间的交互通过Binder实现，线程间通信通过Handler。

       软件层在收到硬件层的vsync信号后，会在Java层向UI的Handler中投递一个消息，进行view数据的计算。这涉及到测量、布局和绘制，通常在`ViewRootImpl`的`performTraversals()`函数中实现。因此，view数据计算在UI的Handler中执行，如果有其他操作在此执行且耗时过长，则可能导致卡顿，我们需要找到并优化这些操作。

       要找到卡顿的原因，可以通过在消息处理前后记录时间，计算时间差，将这个差值与预设的卡顿阈值比较。如果大于阈值，表示发生了卡顿，此时可以dump主线程堆栈并显示给开发者。实现这一功能的关键在于在Looper中设置日志打印类。通过`Looper.loop()`函数中的日志打印，我们可以插入自定义的Printer，并在消息执行前后计算时间差。另一种方法是在日志中添加前缀和后缀，根据这些标志判断时间点。

       BlockCanary是一个用于检测Android应用卡顿的工具，通过源码分析，我们可以了解到它的实现逻辑。要使用BlockCanary，首先需要定义一个继承`BlockCanaryContext`的类，并重写其中的关键方法。在应用的`onCreate()`方法中调用BlockCanary的安装方法即可。当卡顿发生时，BlockCanary会通知开发者，并在日志中显示卡顿信息。

       BlockCanary的核心逻辑包括安装、事件监控、堆栈和CPU信息的采集等。在事件发生时，会创建LooperMonitor，同时启动堆栈采样和CPU采样。当消息将要执行时，开始记录开始时间，执行完毕后停止记录，并计算执行时间。如果时间差超过预设阈值，表示发生了卡顿，并通过回调传递卡顿信息给开发者。

       堆栈和CPU信息的获取通过`AbstractSampler`类实现，它通过`post`一个`Runnable`来触发采样过程，循环调用`doSample()`函数。StackSampler和CpuSampler分别负责堆栈和CPU信息的采集，核心逻辑包括获取当前线程的堆栈信息和CPU速率，并将其保存。获取堆栈信息时，通过在`StackSampler`类中查找指定时间范围内的堆栈信息；获取CPU信息时，从`CpuSampler`类中解析`/proc/stat`和`/proc/mpid/stat`文件的CPU数据，并保存。

       总结而言，BlockCanary通过在消息处理前后记录时间差，检测卡顿情况，并通过堆栈和CPU信息提供详细的卡顿分析，帮助开发者定位和优化性能问题。