语义化版本, semantic versioning 版本号格式为v<major>.<minor>.<patch>，如v1.2.3。当有不兼容的改变时，需要增加 major 版本号，如v2.1.0。 MAJOR.MINOR.PATCH 版本格式: 主版本号.次版本号.修订号，版本号递增规则如下: 主版本号: 当你做了不兼容的API 修改， 次版本号: 当你做了向下兼容的功能性新增， 修订号: 当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面，作为延伸。 semantic versioning https://semver.org/lang/zh-CN/
CPU CPU执行过的指令都遵循以下的流程: CPU首先依据指令指针取得(Fetch)将要执行的指令在代码段的地址，接下来解码(Decode)地址上的指令。解码之后，会进入真正的执行(Execute)阶段，之后会是"写回"(Write Back)阶段，将处理的最终结果写回内存或寄存器中，并更新指令指针寄存器指向下一条指令。 1982年，处理器中引入了指令缓存。 1989年，i486处理器引入了五级流水线。 1995年Intel发布Pentium Pro处理器时，加入了乱序执行核心(Out-of-order core, OOO core)。 乱序执行也并不一定100%达到顺序执行代码的效果。有些时候确实需要引入内存屏障来确保执行的先后顺序。 http://www.infoq.com/cn/articles/x86-high-performance-programming-pipeline?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global 乱序执行 乱序执行 vs 顺序提交 我们知道，在cpu中为了能够让指令的执行尽可能地并行起来，从而发明了流水线技术。但是如果两条指令的前后存在依赖关系，比如数据依赖，控制依赖等，此时后一条语句就必需等到前一条指令完成后，才能开始。 cpu为了提高流水线的运行效率，会做出比如: 1)对无依赖的前后指令做适当的乱序和调度；2)对控制依赖的指令做分支预测；3)对读取内存等的耗时操作，做提前预读；等等。以上总总，都会导致指令乱序的可能。 指令在cpu核内部确实是乱序执行和调度的，但是它们对外表现却是顺序提交的。 Store Buffer https://zhuanlan.zhihu.com/p/141655129 store buffer是什么 在之前的文章介绍中，我们了解到每个CPU都会有自己私有L1 Cache。从我了解的资料来说，L1 Cache命中的情况下，访问数据一般需要2个指令周期。而且当CPU遭遇写数据cache未命中时，内存访问延迟增加很多。硬件工程师为了追求极致的性能，在CPU和L1 Cache之间又加入一级缓存，我们称之为store buffer。store buffer和L1 Cache还有点区别，store buffer只缓存CPU的写操作。store buffer访问一般只需要1个指令周期，这在一定程度上降低了内存写延迟。不管cache是否命中，CPU都是将数据写入store buffer。store buffer负责后续以FIFO次序写入L1 Cache。store buffer大小一般只有几十个字节。大小和L1 Cache相比，确实是小巫见大巫了。 Invalid Queue 超线程 超线程技术就是利用特殊的硬件指令，把一个物理芯片模拟成两个逻辑处理核心，让单个处理器都能使用线程级并行计算，进而兼容多线程操作系统和软件，减少了CPU的闲置时间，提高的CPU的运行效率。这种超线程技术(如双核四线程)由处理器硬件的决定，同时也需要操作系统的支持才能在计算机中表现出来 https://www.cnblogs.com/Survivalist/p/11527949.html ‘查CPU, 核心数’ lscpu cat /proc/cpuinfo |grep name # 总核数 = 物理CPU个数 X 每颗物理CPU的核数 # 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数 # 查看物理CPU个数 cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l # 查看每个物理CPU中core的个数(即核数) cat /proc/cpuinfo| grep "cpu cores"| uniq # 查看逻辑CPU的个数 cat /proc/cpuinfo| grep "processor"| wc -l grep 'model name' /proc/cpuinfo | wc -l Intel CPU Cascade Lake 第二代智能英特尔® 至强® 可扩展处理器，前身为 Cascade Lake，搭载英特尔® C620 系列芯片组（前身为 Purley refresh)， 配有内置英特尔® 深度学习加速（英特尔® DL Boost），可针对人工智能工作负载提供高性能推断和视觉。它可整合多元化的物联网工作负载、处理海量数据集并支持接近实时的交易。现在，借助英特尔® Distribution of OpenVINO™ Toolkit 等已进行 CPU 优化的软件工具套件和框架，您可以获得更好的内置深度学习功能，加快部署速度，并降低总拥有成本 (TCO)。 ...
“Java LockSupport, park unpark” LockSupport.park 调用后,线程状态是 WAITING LockSupport.park() 和 unpark(),与object.wait()和notify()的区别？ 面向的主体不一样。LockSuport主要是针对Thread进行阻塞处理,可以指定阻塞队列的目标对象,每次可以指定具体的线程唤醒。Object.wait()是以对象为纬度,阻塞当前的线程和唤醒单个(随机)或者所有线程。 实现机制不同。虽然LockSuport可以指定monitor的object对象,但和object.wait(),两者的阻塞队列并不交叉。object.notifyAll()不能唤醒LockSupport的阻塞Thread. 阻塞和唤醒是对于线程来说的,LockSupport的park/unpark更符合这个语义,以"线程"作为方法的参数, 语义更清晰,使用起来也更方便。而wait/notify的实现使得"线程"的阻塞/唤醒对线程本身来说是被动的,要准确的控制哪个线程、什么时候阻塞/唤醒很困难, 要不随机唤醒一个线程 (notify) 要不唤醒所有的 (notifyAll) 。 LockSupport.park() (以下简称 park() ) 可能是 java.util.concurrent 包最重要的函数了,因为很多 java.util.concurrent 中的功能类都是利用 park() 来实现它们各自的阻塞。在 park() 之前 Java 也有过类似功能的函数——suspend(),相应的唤醒函数是 resume()。不过 suspend() 有个严重的问题是父线程有可能在调用 suspend() 之前子线程已经调用了 resume(),那么这个 resume() 并不会解除在它之后的 suspend(),因此父线程就会陷入永久的等待中。相比于 suspend(),park() 可以在以下几种情况解除线程的等待状态: 在 park() 前曾经调用过该线程的 unpark() 进而获得了一次"继续执行的权利",此时调用 park() 会立即返回,并且消耗掉相应的"继续执行的权利"。 在 park() 进入等待状态之后,有其他线程以该线程为目标调用 unpark()。 在 park() 进入等待状态之后,有其他线程以该线程为目标调用 interrupt()。 在 park() 进入等待状态之后,有可能会没有理由地解除等待状态。 (这也是为什么推荐在循环体中调用 park(),并在返回之后再次检查条件是否满足。) 其中第一条就可以保证 park() 不会遇到和 suspend() 同样的问题。 最简单的使用 park() 是这样的 ...
MBR GPT http://www.rodsbooks.com/linux-fs-code/ 自从 2007 年 Vista 操作系统推出以后, 各大硬件厂商对硬件开发速度明显加快, 其中对于硬盘的速度和容量, 从最早的 5400 转, 160G 容量, 提升到现在的 7200 转甚至万转机械盘, 容量也先后出现上 TB 级别的。单硬盘都出现 4Tb 容量。 由于磁盘容量越来越大, 传统的 MBR 分区表 (主引导记录) 已经不能满足大容量磁盘的需求。传统的 MBR 分区表只能识别磁盘前面的 2.2TB 左右的空间, 对于后面的多余空间只能浪费掉了,而对于单盘4TB的磁盘,只能利用一半的容量。因此,才有了GPT (全局唯一标识分区表) 。 除此以外,MBR分区表只能支持4个主分区或者3主分区+1扩展分区 (包含随意数目的逻辑分区) ,而GPT在Windows下面可以支持多达128个主分区。 下面IT之家也给大家分享下MBR和GPT的详细区别。 MBR 分区表 在传统硬盘分区模式中,引导扇区是每个分区 (Partition) 的第一扇区,而主引导扇区是硬盘的第一扇区。它由三个部分组成,主引导记录MBR、硬盘分区表DPT和硬盘有效标志。在总共512字节的主引导扇区里MBR占446个字节,第二部分是Partition table区 (分区表) ,即DPT,占64个字节,硬盘中分区有多少以及每一分区的大小都记在其中。第三部分是magic number,占2个字节,固定为55AA。 一个扇区的硬盘主引导记录MBR由4个部分组成。 •主引导程序 (偏移地址0000H-0088H) ,它负责从活动分区中装载,并运行系统引导程序。 •出错信息数据区,偏移地址0089H-00E1H为出错信息,00E2H-01BDH全为0字节。 •分区表 (DPT,Disk Partition Table) 含4个分区项,偏移地址01BEH-01FDH,每个分区表项长16个字节,共64字节为分区项1、分区项2、分区项3、分区项4。 •结束标志字,偏移地址01FE-01FF的2个字节值为结束标志55AA,如果该标志错误系统就不能启动。 GPT 分区表, GUID Partition Map GPT 的分区信息是在分区中,而不象 MBR 一样在主引导扇区, 为保护 GPT 不受 MBR 类磁盘管理软件的危害, GPT 在主引导扇区建立了一个保护分区 (Protective MBR) 的MBR分区表 (此分区并不必要), 这种分区的类型标识为0xEE, 这个保护分区的大小在Windows下为128MB,Mac OS X下为200MB,在Window磁盘管理器里名为GPT保护分区, 可让MBR类磁盘管理软件把GPT看成一个未知格式的分区,而不是错误地当成一个未分区的磁盘。 ...
SonarQube SonarQube (曾用名Sonar (声纳) [1]) 是一个开源的代码质量管理系统。 Sonar是一个用于代码质量管理的开源平台，用于管理源代码的质量，可以从七个维度检测代码质量 提供重复代码、编码标准、单元测试、代码覆盖率、代码复杂度、潜在Bug、注释和软件设计报告 通过插件形式，可以支持包括java,C#,C/C++,PL/SQL,Cobol,JavaScrip,Groovy等等二十几种编程语言的代码质量管理与检测 sonarQube能带来什么？ Developers’ Seven Deadly Sins 1.糟糕的复杂度分布 文件、类、方法等，如果复杂度过高将难以改变，这会使得开发人员难以理解它们， 且如果没有自动化的单元测试，对于程序中的任何组件的改变都将可能导致需要全面的回归测试 2.重复 显然程序中包含大量复制粘贴的代码是质量低下的 sonar可以展示源码中重复严重的地方 3.缺乏单元测试 sonar可以很方便地统计并展示单元测试覆盖率 4.没有代码标准 sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具规范代码编写 5.没有足够的或者过多的注释 没有注释将使代码可读性变差，特别是当不可避免地出现人员变动时，程序的可读性将大幅下降 而过多的注释又会使得开发人员将精力过多地花费在阅读注释上，亦违背初衷 6.潜在的bug sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具检测出潜在的bug 7.糟糕的设计 (原文Spaghetti Design，意大利面式设计) 通过sonar可以找出循环，展示包与包、类与类之间的相互依赖关系 可以检测自定义的架构规则 通过sonar可以管理第三方的jar包 可以利用LCOM4检测单个任务规则的应用情况 检测耦合 关于Spaghetti Design: http://docs.codehaus.org/display/SONAR/Spaghetti+Design 通过sonar可以有效检测以上在程序开发过程中的七大问题 SonarQube安装 预置条件 1.已安装JAVA环境 2.已安装有MySQL数据库 软件下载地址: http://www.sonarqube.org/downloads/ 下载SonarQube与SonarQube Runner 中文补丁包下载: http://docs.codehaus.org/display/SONAR/Chinese+Pack 1.数据库配置 MySQL> CREATE DATABASE sonar CHARACTER SET utf8 COLLATE utf8_general_ci; MySQL> CREATE USER ‘sonar’ IDENTIFIED BY ‘sonar’; MySQL> GRANT ALL ON sonar.* TO ‘sonar’@’%’ IDENTIFIED BY ‘sonar’; ...
RPC, Message Queue, MQ http://oldratlee.com/post/2013-02-01/synchronous-rpc-vs-asynchronous-message RPC 和 MQ 的区别 系统结构 RPC系统结构: Consumer 调用的 Provider 提供的服务。 +———-+—–+———-+ | Consumer | <=> | Provider | +—-+—–+—–+———-+ Message Queue 系统结构: Sender 发送消息给 Queue; Receiver 从 Queue 拿到消息来处理。 +——–+—–+——-+—–+———-+ | Sender | <=> | Queue | <=> | Receiver | +——–+—–+——-+—–+———-+ 功能特点 在架构上, RPC 和 Message 的差异点是, Message 有一个中间结点 Message Queue, 可以存储消息。 消息的特点 Message Queue 缓存请求压力, 然后逐渐释放出来, 消费者可以按照自己的节奏处理数据。 Message Queue 引入一个新的结点, 系统的可靠性会受 Message Queue 的影响。 Message Queue 是异步单向的消息。发送消息设计成是不需要等待消息处理的完成。 所以对于有同步返回需求, 用 Message Queue 则变得麻烦了。 ...
remote dev virtualbox windows 宿主机, archlinux 虚拟机, virtualbox 安装增强包, 使用 seamless mode vscode remote ssh jetbrain remote development beta 版本 不稳定. vm@server, xforward 延迟: 22ms 内存: 16G+ cpu: 8c 无线网带宽问题，延迟 编辑器内部纵向滚动屏幕带宽占用峰值2300KB/s vm@server, rdp Ubuntu 22.04 安装 xrdp 开放 3389 端口, win10 mstsc 连接到 3389, 拖动窗口有延迟, 编辑器内部纵向滚动屏幕延迟可以接受. 拖动窗口带宽占用峰值 1700KB/s, 编辑器内部纵向滚动屏幕带宽占用峰值500KB/s 延迟: 22ms 内存: 16G+ cpu: 8c vm@server, vnc 延迟: 22ms 内存: 16G+ cpu: 8c 图形界面延迟 基于像素的传输,画质不好. wsl + x server 延迟: <1ms 内存: 16G+ cpu: 4c 内存占用问题 wsl + idea 延迟: <1ms 内存: 16G+ cpu: 4c 磁盘性能问题 windows + idea 延迟: <1ms 内存: 16G+ cpu: 4c ansible,git,leveldb 问题
协程, Coroutine 协程别名: 微线程，纤程。英文:Coroutine, Green threads, fibers 传统编程语言中子程序或者函数是层级调用的,函数可以调用其它函数, 调用者需要等待被调用者结束之后继续执行, 函数调用是通过栈实现的. 一个线程就是按顺序执行一个或几个子函数, 函数调用只有一个入口和一个出口. 协程看上去也是函数,但是执行过程中在子程序内部可以中断,然后执行别的函数, 然后再被调度回来执行. 协程比线程有更高的执行效率, 协程没有线程切换的开销 协程在用户空间调度, 不涉及系统调用或任何阻塞调用, 不需要用来守卫关键区块的同步性原语（primitive）比如互斥锁、信号量等，并且不需要来自操作系统的支持 协程不需要多线程的锁机制, 为只有一个线程，也不存在同时写变量冲突，在协程中控制共享资源不加锁，只需要判断状态就好了，所以执行效率比多线程高很多。 协程是协作式多任务的, 线程典型是抢占式多任务的 因为协程是一个线程执行，那怎么利用多核CPU呢？最简单的方法是多进程+协程，既充分利用多核，又充分发挥协程的高效率，可获得极高的性能。 使用抢占式调度的线程实现协程，但是会失去某些利益（特别是对硬性实时操作的适合性和相对廉价的相互之间切换）。 协程是语言层级的构造，可看作一种形式的控制流，而线程是系统层级的构造。 名词对照 coroutine、goroutine、virtual thread、轻量级线程、协程、虚拟线程、用户态线程、绿色线程——这些名词基本上在说同一类东西，只是来自不同语言和时代： 术语 说明 coroutine（协程） 最广义的概念，包括协作式（asyncio）和抢占式（goroutine）两类 goroutine Go 的实现，抢占式，属于协程的子集 virtual thread（虚拟线程） Java 21 的叫法，强调"就是线程，只是轻量" green thread（绿色线程） 早期术语，泛指用户态管理的线程 用户态线程 / 轻量级线程 描述实现机制的技术术语 命名不同有历史原因： Go 作者刻意不叫"协程"，因为传统协程是协作式的，而 goroutine 是运行时抢占式调度的，更像轻量级线程 Java 叫"虚拟线程"是为了向后兼容——复用 Thread API，让现有代码改动最小 严格说，asyncio 协程（协作式、无栈）和 goroutine / 虚拟线程（抢占式、有栈）不是一回事，但常被混称为"协程"。 为什么需要用户态线程 OS 线程太重了 一个 OS 线程的代价： 默认栈大小 1~8 MB（Linux 默认 8MB） 创建/销毁需要系统调用，耗时微秒级 上下文切换需要陷入内核，保存/恢复大量寄存器 线程数受 OS 限制，通常几千到几万个 典型场景：一个 HTTP 服务，每个请求一个线程，1 万并发连接 → 80GB 内存光用在栈上，还没开始干活。 ...
QNAP qnap, plex server, apple tv, av1 https://www.reddit.com/r/PleX/comments/12pe5tx/comment/jgrrjnc/ https://github.com/currifi/plex_av1_tvos?tab=readme-ov-file https://support.plex.tv/articles/202915258-where-is-the-plex-media-server-data-directory-located/ https://www.qnap.com/en/how-to/faq/article/how-do-i-access-my-qnap-nas-using-ssh QNAP 启用 ssh 服务 ssh admin@192.168.50.227 # print The exact data directory location getcfg -f /etc/config/qpkg.conf PlexMediaServer Install_path mkdir /share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/Library/Plex Media Server/Profiles # copy file https://github.com/scriptsingh/plex_av1_tvos/blob/main/tvOS.xml to Profiles dir 重启 plex server 威联通 nas web ui> app center> plex server stop start
mutex, 锁 Mutual exclusion (或者锁) 的实现有硬件实现和软件实现, 软件实现是通过一些特别的算法譬如 Peterson’s algorithm,这类软件实现通常比硬件实现需要更多的内存,而且由于现代计算机的乱序执行,需要手动加memory barrier来保证memory ordering,这里暂时不做讨论纯软件实现。CPU如果提供一些用来构建锁的atomic指令,一般会更高效一些。 锁的本质 所谓的锁,在计算机里本质上就是一块内存空间。当这个空间被赋值为1的时候表示加锁了,被赋值为0的时候表示解锁了,仅此而已。多个线程抢一个锁,就是抢着要把这块内存赋值为1。在一个多核环境里,内存空间是共享的。每个核上各跑一个线程,那如何保证一次只有一个线程成功抢到锁呢？你或许已经猜到了,这必须要硬件的某种 guarantee。具体的实现如下。 硬件 CPU如果提供一些用来构建锁的 atomic 指令, 譬如 x86 的 CMPXCHG (加上LOCK prefix), 能够完成 atomic 的 compare-and-swap (CAS), 用这样的硬件指令就能实现 spin lock. 本质上 LOCK 前缀的作用是锁定系统总线 (或者锁定某一块cache line) 来实现atomicity,可以了解下基础的缓存一致协议譬如MSEI。简单来说就是,如果指令前加了LOCK前缀,就是告诉其他核,一旦我开始执行这个指令了,在我结束这个指令之前,谁也不许动。缓存一致协议在这里面扮演了重要角色,这里先不赘述。这样便实现了一次只能有一个核对同一个内存地址赋值。 操作系统 mutex在linux内核中由 futex 系统调用支撑，如果没有竞争不需要陷入内核；内核的主要是 futex_wait/wake 函数配合上层完成业务逻辑； 一个 spin lock 就是让没有抢到锁的线程不断在 while 里面循环进行 compare-and-swap, 燃烧CPU, 浪费青春, 直到前面的线程放手 (对应的内存被赋值0) 。这个过程不需要操作系统的介入,这是运行程序和硬件之间的故事。如果需要长时间的等待,这样反复CAS轮询就比较浪费资源,这个时候程序可以向操作系统申请被挂起,然后持锁的线程解锁了以后再通知它。这样CPU就可以用来做别的事情,而不是反复轮询。 但是OS切换线程也需要一些开销,所以是否选择被挂起,取决于大概是否需要等很长时间,如果需要,则适合挂起切换为别的线程。线程向操作系统请求被挂起是通过一个系统调用,在linux上的实现就是 futex, 宏观来讲, OS需要一些全局的数据结构来记录一个被挂起线程和对应的锁的映射关系,这样一个数据结构天然是全局的,因为多个OS线程可能同时操作它。所以,实现高效的锁本身也需要锁。有没有一环套一环的感觉？futex的巧妙之处就在于,它知道访问这个全局数据结构不会太耗时,于是futex里面的锁就是spin lock。linux上pthread mutex 的实现就是用的 futex 。更多精彩内存参考talk: https://www.infoq.com/presentations/go-locks/ 用户态的锁 像Goroutine线程就是go runtime来调度的,而不是OS,所以go routine线程切换的开销要远小于OS线程切换的开销。Goroutine的本质就是一个coroutine,这种轻量的线程在很多语言的runtime里面都有实现。最近Java也有了 (project loom) 。 ...
ASCII Dec Hex Char 10 0A LF 13 0D CR 32 20 Space 35 30 # 48 30 0 57 39 9 58 3A : 65 41 A 66 42 B 67 43 C 70 46 F 73 49 I 90 5A Z 97 61 a 101 65 e 102 66 f 115 73 s 122 7A z 124 7C | ASCII字符集，最基本的包含了128个字符。其中前32个，0-31，即0×00-0x1F，都是不可见字符。这些字符，就叫做控制字符。 这些字符没法打印出来，但是每个字符，都对应着一个特殊的控制功能的字符，简称功能字符或功能码Function Code。 简言之: ASCII中前32个字符，统称为Function Code功能字符。 此外，由于ASCII中的127对应的是Delete，也是不可见的，所以，此处根据笔者的理解，也可以归为Function Code。 此类字符，对应不同的"功能"，起到一定的"控制作用"，所以，称为控制字符。 ...
cpu瓶颈分析 #系统的平均负载 uptime # 每个 CPU 的使用情况 mpstat # 每个进程 CPU 的使用情况 pidstat stress stress https://www.hi-linux.com/posts/59095.html https://www.infoq.cn/article/5jjIdOPx12RWWvGX_H9J?utm_source=rss&utm_medium=article http://9leg.com/java/2016/08/09/cpu-consumption-analysis.html 通常性能瓶颈的表现是资源消耗过多、外部处理系统的性能不足，或者资源消耗不多，但程序的响应速度却达不到要求。 资源主要消耗在cpu，io (又分文件io和网络io) ，内存方面，机器的资源是有限的，当某资源消耗过多时，通常会造成系统的响应速度变慢。 对于java应用而言，寻找性能瓶颈的方法通常为首先分析资源的消耗，然后结合java的一些工具来查找程序中造成资源消耗过多的代码。 今天先谈一谈cpu消耗如何分析，系统为linux，jdk为sun jdk。 在linux中，cpu主要用于中断、内核和用户进程的任务处理，优先级为中断>内核>用户进程，下面先讲述三个重要的概念。 上下文切换 每个cpu (多核cpu中的每个cpu) 在同一时间只能执行一个线程，linux采用的是抢占式调度。为每个线程分配一定的执行时间， 当到达执行时间、线程中有io阻塞或高优先级的线程要执行时，linux将切换执行的线程，在切换时要存储目前的线程的执行状态， 并恢复要执行的线程的状态，这个过程就是上下文切换。对于java应用而言，典型的是在进行文件io操作、网络io操作、锁等待或者线程sleep时， 当前线程会进入阻塞或休眠状态，从而触发上下文切换，上下文切换过多会造成内核占据较多的cpu使用，从而使应用响应速度变慢。 运行队列 每个cpu核都会维护一个可运行的线程队列，例如一个4核的cpu，java应用里启动了8个线程，且这8个线程都处于可运行状态， 那么在分配平均的情况下每个cpu中的运行队列就会有2个线程。通常而言，系统的load主要由cpu运行队列来决定。 利用率 cpu利用率为cpu在用户进程、内核、中断处理、io等待以及空闲5个部分使用的百分比，这5个值是用来分析cpu消耗的关键指标。 在linux中，可通过top或pidstat方式来查看进程中线程的cpu的消耗状况。 top 输入top命令后既可查看cpu的消耗情况，cpu的信息在top视图的上面几行中 对于多个或多核cpu，上面的显示则会是多个cpu所占用的百分比总合。如需查看每个核的消耗情况，可在进入top视图后按1，就会按核来显示消耗情况。 cpu-top 默认情况下，top视图中显示的为进程的cpu消耗状况，在top视图中按shift + h后，可按线程查看cpu的消耗状况，此时的pid既为线程id。 pidstat sy过高 当sy值过高时，表示linux花费了更多的时间在进行线程切换。java应用造成这种现象的主要原因是启动的线程比较多， 且这些线程多处于不断的阻塞 (例如锁等待，io等待) 和执行状态的变化过程中，这就导致了操作系统要不断的切换执行的线程， 产生大量的上下文切换。在这种情况下，对java应用而言，最重要的是找出不断切换状态的原因， 可采用的方法为通过kill -3 pid 或jstack -l pid的方法dump出java应用程序的线程信息，查看线程的状态信息以及锁信息， 找出等待状态或锁竞争过多的线程。 进程和线程的上下文切换都涉及进出系统内核和寄存器的保存和还原，这是它们的最大开销。但与进程的上下文切换相比，线程还是要轻量一些， 最大的区别是线程上下文切换时虚拟内存地址保持不变，所以像TLB等CPU缓存不会失效。但要注意的是另一份提问 What is the overhead of a context-switch?的中提到了: Intel和AMD在2008年引入的技术可能会使TLB不失效。 ...
How browsers work http://taligarsiel.com/Projects/howbrowserswork1.htm http://ux.sohu.com/topics/50972d9ae7de3e752e0081ff
Spinlock(自旋锁), Ticket Spinlock, MCS Spinlock 为什么要加锁 在 SMP 系统中,如果仅仅是需要串行地增加一个变量的值,那么使用原子操作的函数 (API) 就可以了。但现实中更多的场景并不会那么简单,比如需要将一个结构体A中的数据提取出来,然后格式化、解析,再添加到另一个结构体B中,这整个的过程都要求是「原子的」,也就是完成之前,不允许其他的代码来读/写这两个结构体中的任何一个。 这时,相对轻量级的原子操作API就无法满足这种应用场景的需求了, 我们需要一种更强的同步/互斥机制,那就是软件层面的「锁」的机制。 同步锁的「加锁」和「解锁」是放在一段代码的一前一后,成对出现的,这段代码被称为 Critical Section / Region (临界区) 。但锁保护的并不是这段代码本身,而是其中使用到的多核/多线程共享的变量,它「同步」(或者说串行化) 的是对这个变量的访问,通俗的语义就是“我有你就不能有,你有我就不会有”。 Linux中主要有两种同步锁,一种是 spinlock,一种是 mutex. spinlock 和 mutex 都既可以在用户进程中使用,也可以在内核中使用,它们的主要区别是: 前者不会导致睡眠和调度,属于 busy wait 形式的锁, 后者可能导致睡眠和调度,属于 sleep wait 形式的锁。 spinlock 是最基础的一种锁,像后面将要介绍的 rwlock(读写锁), seqlock(读写锁)等都是基于spinlock衍生出来的。就算是 mutex,它的实现与spinlock 也是密不可分。因此,本系列文章将首先围绕 spinlock展开介绍。 如何加锁 Linux 中 spinlock 机制发展到现在,其实现方式的大致有3种。 第一种实现 - 经典的 CAS 最古老的一种做法是: spinlock 用一个整形变量表示,其初始值为1,表示 available 的状态。当一个CPU (设为CPU A) 获得spinlock后,会将该变量的值设为0,之后其他CPU试图获取这个 spinlock 时,会一直等待,直到 CPU A 释放 spinlock, 并将该变量的值设为1。 那么其他的 CPU 是以何种形式等待的,如果有多个CPU一起等待,形成了竞争又该如何处理？ 这里要用到经典的 CAS 操作 (Compare And Swap) 。 ...
The MIT License http://baike.baidu.com/view/3159946.htm MIT许可证 (The MIT License) 是许多软件授权条款中,被广泛使用的其中一种。与其他常见的软件授权条款 (如GPL、LPGL、BSD) 相比,MIT是相对宽松的软件授权条款。MIT许可证之名源自麻省理工学院 (Massachusetts Institute of Technology, MIT) ,又称"X条款" (X License) 或"X11条款" (X11 License) MIT内容与三条款BSD许可证 (3-clause BSD license) 内容颇为近似,但是赋予软件被授权人更大的权利与更少的限制。有许多团体均采用MIT许可证。例如著名的ssh连接软件PuTTY与X Windows System (X11)即为例子。Expat, Mono开发平台库,Ruby on Rails, Lua 5.0 onwards等等也都采用MIT授权条款。被授权人权利 被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软件及软件的副本。 被授权人可根据程序的需要修改授权条款为适当的内容。 被授权人义务 在软件和软件的所有副本中都必须包含版权声明和许可声明。 其他重要特性 此授权条款并非属copyleft的自由软件授权条款,允许在自由/开放源码软件或非自由软件 (proprietary software) 所使用。 MIT的内容可依照程序著作权者的需求更改内容。此亦为MIT与BSD (The BSD license, 3-clause BSD license) 本质上不同处。 MIT条款可与其他授权条款并存。另外,MIT条款也是自由软件基金会 (FSF) 所认可的自由软件授权条款,与GPL兼容。
Lua http://zh.wikipedia.org/zh-cn/Lua http://baike.baidu.com/view/416116.htm Lua ( /ˈluːə/ ) 程序设计语言是一个简洁、轻量、可扩展的脚本语言，是葡萄牙语中"Luna" (月亮) 的意思。 Lua 是一个动态弱类型语言，支援增量式垃圾收集策略。有内建的，与操作系统无关的协作式多线程 (coroutine) 支持 Lua的目标是成为一个很容易嵌入其它语言中使用的语言。大多数程序员也认为它的确做到了这一点。 很多应用程序使用Lua作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。这其中包括大话西游II、仙境传说、魔兽世界、战锤40k、博德之门、轩辕剑外传汉之云、愤怒的小鸟等。 Lua是一种轻量语言，它的官方版本只包括一个精简的核心和最基本的库。这使得Lua体积小、启动速度快。它用标准C语言编写并以源 代码形式开放，编译后仅仅一百余K，可以很方便的嵌入别的程式里。和许多"大而全"的语言不一样，网路通讯、图形界面等都没有默认提供。但是Lua可以很 容易地被扩展: 由宿主语言 (通常是C或C++) 提供这些功能，Lua可以使用它们，就像是本来就内置的功能一样。事实上，现在已经有很多成熟的扩展模块可供选用。 Lua是一种多重编程范式的程式设计语言: 它只提供了很小的一个特性集合来满足不同编辑范式的需要，而不是为某种特定的编辑范式提供繁杂的特性支援。例如，Lua并不提供继承这个特性，但是你可以用元表来模拟它。诸如名字空间、类这些概念都没有在语言基本特性中实现，但是我们可以用表结构 (Lua唯一提供的复杂数据结构) 轻易模拟。Lua可以在运行时随时构造出一个函数，并把它看作一个对象 (正是所谓的first class function) ，这个特性可以很好的满足函数式编程的需要。这是提供了这些基本的元特性，我们可以任意的对语言进行自需的改造。 Lua 原生支援的数据类型非常之少，它只提供了数字 (缺省是双精度浮点数，可配置) 、布尔量、字符串、表、子程序、协程 (coroutine) 以及用户自定义数据这几种。但是其处理表和字符串的效率非常之高，加上元表的支援，我们可以高效的模拟出需要的复杂数据类型 (比如集合、数组等) 。
快速匹配字符串 假设内存有一个大字符串集,里面含有约1000万个字符串,如何快速知道该字符串集是否含有某个指定的测试字符串 ? (假设内存能放下这么多字符串) 方法一: hashCode法 方法二: Trie树 http://zh.wikipedia.org/wiki/Trie HashCode法 01 def sampleHashMap(strSet: Set[String]): Map[Int, Set[String]]={ 02 strSet.groupBy{ 03 s => s.hashCode 04 } 05 } 06 07 def contain(str: String, sampleMap: Map[Int, Set[String]]): Boolean = { 08 sampleMap.getOrElse(str.hashCode, Set[String]()).exists(_ equals str) 09 } 10 11 // 测试 12 val sampleSet = Set("a","b","c","AA","Archer","Jack"); 13 val sampleMap = sampleHashMap(sampleSet); 14 println(contain("Archer", sampleMap)); // true 15 println(contain("A", sampleMap)); // false 16 println(contain("a", sampleMap)); // true Trie树法 01 sealed abstract class Trie { 02 def contains(msg: String): Boolean = contains(msg, this) 03 04 @scala.annotation.tailrec 05 private def contains(msg: String, trie: Trie): Boolean = (msg, trie) match { 06 case (null, _ ) | (_ , null ) => false 07 case (StringCase(head, tail), TrieNode(edges)) => edges.get(head) match { 08 case None => false 09 case Some(subTrie) => contains(tail,subTrie) 10 } 11 case (StringCase(_,_), TrieLeaf()) => false 12 case _ => true 13 } 14 } 15 16 case class TrieNode(edges: Map[Char, Trie]) extends Trie{ 17 assert(edges.size > ) 18 } 19 case class TrieLeaf extends Trie 20 21 object StringCase{ 22 def unapply(s: String): Option[(Char, String)] ={ 23 if (s == null || s == "" ) None 24 else Some(s.head, s.tail) 25 } 26 } 27 28 object Trie{ 29 30 def apply(strs: String*): Trie ={ 31 apply(strs.toSet); 32 } 33 34 def apply(strSet: Set[String]) : Trie = { 35 if (strSet.size == || strSet == Set("")) TrieLeaf() 36 else { 37 val char2TrieSet = strSet.filter(_.length > ).groupBy(_.head).mapValues{ 38 strs => strs.map(_.tail) 39 }.mapValues{ 40 strs => apply(strs) 41 } 42 TrieNode(char2TrieSet); 43 } 44 } 45 46 } 47 48 val trie= Trie("abc","ac","b") 49 println(trie) 50 assert(trie.contains("") == true); // true 51 assert(trie.contains(null) == false); //false 52 assert(trie.contains("a") == true); // true 53 assert(trie.contains("b") == true); // true 54 assert(trie.contains("ab") == true); //true 55 assert(trie.contains("ac") == true); //true 56 assert(trie.contains("abc") == true); //true 57 assert(trie.contains("acb") == false); // false 58 assert(trie.contains("abcd") == false); //false 59 assert(trie.contains("bc") == false); //false
Lambda 表达式 “Lambda 表达式"是一个匿名函数,它可以包含表达式和语句,并且可用于创建委托或表达式目录树类型。 所有 Lambda 表达式都使用 Lambda 运算符 =>,该运算符读为"goes to”。该 Lambda 运算符的左边是输入参数 (如果有) ,右边包含表达式或语句块。Lambda 表达式 x => x * x 读作"x goes to x times x"。 函数式接口functional interface, @FunctionalInterface 函数式接口(Functional Interface)是Java 8对一类特殊类型的接口的称呼。 这类接口只定义了唯一的抽象方法的接口 (除了隐含的Object对象的公共方法) , 因此最开始也就做SAM类型的接口 (Single Abstract Method) 。 为什么会单单从接口中定义出此类接口呢？ 原因是在 Java Lambda 的实现中, 开发组不想再为Lambda表达式单独定义一种特殊的Structural函数类型,称之为箭头类型 (arrow type) , 依然想采用Java既有的类型系统(class, interface, method等), 原因是增加一个结构化的函数类型会增加函数类型的复杂性,破坏既有的Java类型,并对成千上万的Java类库造成严重的影响。 权衡利弊, 因此最终还是利用SAM 接口作为 Lambda表达式的目标类型。 JDK中已有的一些接口本身就是函数式接口,如Runnable。 JDK 8中又增加了java.util.function包, 提供了常用的函数式接口。 函数式接口代表的一种契约, 一种对某个特定函数类型的契约。 在它出现的地方,实际期望一个符合契约要求的函数。 Lambda表达式不能脱离上下文而存在,它必须要有一个明确的目标类型,而这个目标类型就是某个函数式接口。 方法引用 (method reference) 双冒号 “::” 是 Java 8 引入 Lambda 表达式后的一种用法,表示方法引用 (method reference) ,可以更加简洁的实例化接口 双冒号表达式返回的是一个 函数式接口对象 (用 @FunctionalInterface 注解的 interface 类型) 的实例,如下: ...
消息队列/message queue/MQ, CORBA, DCOM, RMI, RPC http://blog.csdn.net/mr_smile2014/article/details/47452281 消息队列是在消息的传输过程中保存消息的容器，消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。 一、 产生背景: 现今，越来越多的企业面临着各种各样的数据集成和系统整合，CORBA、DCOM、RMI 等RPC中间件技术也应运而生，但由于采用RPC同步处理技术，在性能、健壮性、可扩展性上都存在着诸多缺点。而基于消息的异步处理模型采用非阻塞的调用特性，发送者将消息发送给消息服务器，消息服务器在合适的时候再将消息转发给接收者；发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同，而且发送者可以将消息间接传给多个接收者，大大提高了程序的性能、可扩展性及健壮性，这使得异步处理模型在分布式应用上比起同步处理模型更具有吸引力。 分布式对象调用，如CORBA，RMI 和DCOM，提供了一种通讯机制，透明地在异构的分布式计算环境中传递对象请求，这些对象可以位于本地或远程机器。它通过在对象与对象之间提供一种统一的接口，使对象之间的调用和数据共享不再关心对象的位置、实现语言及所驻留的操作系统。这个接口就是面向对象的中间件。 二、传统面向对象中间件的局限性 同步通信: 客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行。 客户和服务对象的生命周期紧密耦合: 客户进程和服务对象进程都必须正常运行，如果由于服务对象崩溃或网络故障导致客户的请求不可达，客户会接收到异常。 三、面向消息的中间件的优越性 消息中间件作为一个中间层软件, 它为分布式系统中创建、发送、接收消息提供了一套可靠通用的方法，实现了分布式系统中可靠的、高效的、实时的跨平台数据传输。消息中间件减少了开发跨平台和网络协议软件的复杂性，它屏蔽了不同操作系统和网络协议的具体细节，面对规模和复杂度都越来越高的分布式系统。它与传统的面向对象中间件相比具有如下优点: 采用异步通信模式: 发送消息者可以在发送消息后进行其它的工作，不用等待接收者的回应，而接收者也不必在接到消息后立即对发送者的请求进行处理。 客户和服务对象生命周期的松耦合关系: 客户进程和服务对象进程不要求都正常运行，如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户不会接收到异常，消息中间件能保证消息不会丢失。 四、消息中间件的技术标准 消息中间件主要有JMS和AMQP两种技术标准； JMS Java关于消息服务的标准是JMS，JMS即Java消息服务 (Java Message Service) 应用程序接口是一个Java平台中关于面向消息中间件 (MOM) 的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，类似于JDBC，需要不同的提供商进行各自的实现。实现JMS标准的软件可以作为Java下的消息中间件服务器。JMS 使您能够通过消息收发服务 (有时称为消息中介程序或路由器) 从一个 JMS 客户机向另一个 JMS客户机发送消息。消息是 JMS中的一种类型对象，由两部分组成: 报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载的类型来划分，可以将消息分为几种类型，它们分别携带: 简单文本(TextMessage)、可序列化的对象 (ObjectMessage)、属性集合 (MapMessage)、字节流 (BytesMessage)、原始值流 (StreamMessage)，还有无有效负载的消息 (Message)。 AMQP AMQP，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。Erlang中的实现有 RabbitMQ等。
Smalltalk Smalltalk被公认为历史上第二个面向对象的程序设计语言和第一个真正的集成开发环境 (IDE)。由Alan Kay，Dan Ingalls，Ted Kaehler，Adele Goldberg等于70年代初在Xerox PARC开发。Smalltalk对其它众多的程序设计语言的产生起到了极大的推动作用，主要有: Objective-C，Actor， Java 和Ruby等。90年代的许多软件开发思想得利于Smalltalk，例如Design Patterns， Extreme Programming(XP)和Refactoring等。 Smalltalk和许多程序设计语言不同，它不仅仅是一门语言。 一种面向对象的程序设计语言: 它是一种面向对象的语言，包含语言的语法和语义。一些编译器可以通过 Smalltalk 源程序产生可执行文件。这些编译器通常产生一种能在虚拟机上运行的二进制代码。Smalltalk语言本身非常精炼。 一种程序设计环境: 这里指的是一种提供许多 对象 的系统，而不是某种特殊的开发环境。和许多语言不同(包括C++)，Smalltalk附带有一个巨大的、相当标准的类库。这些 类 使得开发Smalltalk程序的效率非常高。在其它语言 (例如 Ada ， C 和 Pascal ) 中通常被作为语言的一部分的功能 (例如条件判断，循环等)，在Smalltalk由特定的类提供。 **一个应用开发环境(ADE):**由于Smalltalk的历史原因，它具有一个非常优秀的高度集成、开放的应用开发环境。由于开发环境中的浏览器、监视器以及调试器都由同样的源程序衍生出来的，不同的版本之间也具有相当好的兼容性。此外，这些工具的源程序都可以在ADE直接存取。