在vxWorks操作系统中创建dosFs文件系统
文件系统,是指操作系统依据文件夹和文件的组织形式在磁盘设备上应用的一种设备驱动,不同的文件系统对文件夹和文件有不同的限制(如文件夹名限制,文件限制大小等)。
VxWorks支持多种文件系统,比較重要的有:
1、dosFs:适用于块存取设备(比方硬盘、软盘)。和MS-DOS文件系统兼容;
2、rawFs:提供了一种简单的原始文件系统。该文件系统将整个硬盘当作一个单独的大文件;
3、cdromFs:同意系统从依照ISO9660标准文件系统格式化的CD-ROM上读取设备;
通常文件系统驱动位于磁盘(块存取)设备驱动和IO系统之间,这一点在VxWorks中也不例外,但它在此基础上扩充了功能,即在文件系统下方添加了一个CBIO(Core Blocked IO)接口,在CBIO下方才是块存取设备驱动,其示意图例如以下:
图1 VxWorks I/O系统层次图
而CBIO接口部分又细分为4个逻辑子层,每一个逻辑层都有与创建文件系统相关的函数,将CBIO接口部分细分后。包括各子层相关操作函数的VxWorks文件系统示意图例如以下:
图2 CBIO层内部结构层次图
图中线框中的四层就是CBIO接口层里的子层。对内核配置了dosFs支持的VxWorks来说,对磁盘的管理是从BLK_DEV API设备驱动子层上開始的,不同子层上的函数创建出的CBIO句柄分属不同的层,下层的CBIO句柄即为上层CBIO句柄的附属CBIO句柄。也就是说它们尽管都是CBIO_DEV_ID类型,但依据产生它们的函数所在的层把它们按等级划分,一个CBIO缓冲区能够在每一个子层上都有一个CBIO句柄,也能够在部分子层上有CBIO句柄。CBIO缓冲区在基本CBIO to BLK_DEV设备子层上就没有句柄。图右側函数间的箭头指示了各子层间句柄的关系。此外,从图中能够看出,头文件也是依据层的划分来组织的。这样使得函数调用层次清晰。
2 在磁盘上建立dosFs文件系统
以运行在摩托罗拉公司的PPC860 CPU上的VxWorks为例,在配置VxWorks内核时加入IDE/ATA磁盘设备驱动,在系统启动后,系统就和磁盘相连,系统启动后会发现磁盘(运行指令:devs,列出的设备中有一个/ata0a),此时该设备尚无法訪问(就像刚出厂的硬盘用启动盘引导后能发现却不能使用一样。在dos下须要用fdisk工区来创建分区,格式化后才干使用),而在VxWorks下,系统也提供了相似的操作(如图2)。
在创建文件系统之前,应通过在内核中包括dosFs组件来初始化dosFs文件系统,即让系统载入文件系统驱动。同意系统在块设备上创建文件系统设备。
至此,系统启动后。用户直接面向的已经是BLK_DEVAPI设备驱动子层了。全部的操作都是从该层上方開始的。
为了在磁盘上上创建分区、格式化并使用它,应进行以下操作:
2.1创建块存取设备:
对于磁盘设备,使用ataDevCreate()函数在BLK_DEV API设备驱动子层上创建一个指向块存取设备的指针pAta:
BLK_DEV * ataDevCreate(int ctrl,intdrive,int nBlocks,int blkOffset)
參数1表示磁盘设备控制器号。0表示primary,
參数2表示磁盘设备驱动器号,0表示master。
參数3表示驱动器设备上的块数量,0表示使用整个磁盘,
參数4表示从驱动器開始处偏移的块数量。0表示从头開始。
函数为指定的ATA/IDE磁盘或ATAPI CDROM创建一个设备。返回一个指向块设备结构(BLK_DEV)的指针。图2中在此处用pAta=ataDevCreate(0,0,0,0)创建一个指向块设备的指针pAta。该设备相应磁盘primary master,而且使用整个磁盘的从头開始的全部块。(不要混淆设备和磁盘。能够把磁盘的一部分创建为一个设备。即一个设备相应于一个磁盘和该磁盘里的块,而磁盘由控制器号和驱动器号唯一指定)
2.2 创建磁盘快速缓冲区:
该步骤是可选的。
通过调用dcacheDevCreate()函数为一个块设备创建磁盘快速缓冲区并在CBIO to CBIO设备(dcacheCbio)子层上生成CBIO句柄。使用方法例如以下:
CBIO_DEV_ID dcacheDevCreate(CBIO_DEV_ID subDev,char *pRamAddr,int memSize,char*pDesc)
參数1表示一个CBIO句柄。该句柄作为返回的CBIO to CBIO设备(dcacheCbio)子层的CBIO句柄的附属CBIO句柄,该附属句柄由函数CBIO_DEV_ID cbioWrapBlkDev(BLK_DEV *)在基本CBIO to BLK_DEV设备(cbioLib)子层上生成。也能够使用块设备,当使用块设备时,实际上是将块设备转换成在基本CBIO to BLK_DEV设备(cbioLib)子层上的CBIO句柄后作为參数的;
參数2表示该CBIO快速缓冲区在内存中的位置。
參数3表示为该CBIO快速缓冲区使用多少内存;
參数4表示设备描写叙述字符串。
函数创建一个CBIO层磁盘快速缓冲区实例,并在CBIO to CBIO设备(dcacheCbio)子层生成CBIO句柄,当參数2为NULL时,參数3使用全部内存缓冲磁盘数据。当參数2为0时,參数3使用一个默认内存大小缓冲磁盘数据。參数4为设备描写叙述字符串。会在dcacheShow运行时作为结果的一部分输出。
当须要多个快速缓冲区时非常须要(支持16个快速缓冲区)。
当内存容量小于指定缓冲区大小时创建失败。
图2中此处用cbio=dcacheDevCreate(pAta,0,0,“cache1”)为块设备pAta创建默认大小的快速缓冲区cbio,同一时候cbio也是该缓冲区在CBIOto CBIO设备(dcacheCbio)子层上的CBIO句柄。
这里用块设备作为參数1比較直观。并描写叙述为“cache1”。也能够先使用bcbio=cbioWrapBlkDev(pAta),再使用cbio=dcacheDevCreate(bcbio,0,0,“cache1”),此时bcbio为cbio的附属句柄。
2.3 创建和安装磁盘分区:
通过调用usrFdiskPartCreate()在磁盘上创建分区表。然后通过调用dpartDevCreate()初始化一个分区的磁盘。并在CBIO to CBIO设备(dpartCbio)子层上创建CBIO句柄。例如以下:
STATUSusrFdiskPartCreate(CBIO_DEV_ID cDev,int nPart,int size1,int size2,int size3)
參数1表示一个CBIO句柄,分区表将在这个代表整个磁盘的句柄相应的块设备上创建,注意这里不是subDev,而是cDev,表示不要用附属CBIO句柄bcbio,而应使用cbio;
參数2表示要创建的分区数,默觉得1。最大为4;
參数3表示第2个分区所占用的空间百分比。
參数4表示第3个分区所占用的空间百分比;
參数5表示第4个分区所占用的空间百分比。
该程序用来创建基本分区表,即对磁盘分区,仅仅能用来创建一个主分区表。即MBR,不能用于创建启动或扩展分区。返回一个指示操作成功与否的状态值。
这时磁盘仅仅有分区表,还没有安装分区,能够用usrFdiskPartShow()显示创建的分区。
图2中此处用usrFdiskPartCreate(cbio,2,50,0,0)在cbio相应的块设备上创建两个分区。各占磁盘一半空间。
创建磁盘分区的操作函数dpartDevCreate()使用方法例如以下:
CBIO_DEV_ID dpartDevCreate(CBIO_DEV_IDsubDev,int nPart,FUNCPTR pPartDecodeFunc)
參数1表示一个附属CBIO句柄,即存在于以下子层上的cbio。
參数2表示分区数量,
參数3表示能解释分区表的函数。
为了处理一个已分区的磁盘,即在磁盘上安装分区,须要使用该函数。推荐为了操作的高效,为整个磁盘创建一个快速缓冲区并在各分区间共享该快速缓冲区。nPart參数表示特定磁盘驱动器上最大的分区数,可支持最多24个。
分区表解释程序:应该实现的功能是将已分区设备的分区信息解释成特定格式的结果。并将结果写入一个特定类型的表中。
图2中此处通过调用cbio1=dpartDevCreate(cbio,2,usrFdiskPartRead)通过让usrFdiskPartRead程序解释cbio相应块设备的分区表来初始化分区的磁盘。usrFdiskPartRead程序是系统提供的解释分区表信息的程序,可直接调用。至此分区操作完毕。在创建文件系统和格式化分区后就可以使用分区了。注意程序返回的cbio1尽管和cbio类型同样,注意生成的句柄cbio1位于CBIO to CBIO设备(dpartCbio)子层上。
2.4 创建dosFs文件系统:
文件系统在VxWorks中也被看作一个设备。通过调用函数dosFsDevCreate()来在指定分区上创建dosFs文件系统。dosFsDevCreate()函数使用方法为:
STATUS dosFsDevCreate(char*pDevName,CBIO_DEV_ID cbio,u_int maxFiles,u_int autoChkLevel)
參数1表示创建文件系统后,相应分区的卷名,格式为“/卷名”;
參数2表示特定分区的CBIO句柄,对本例,即用dpartPartGet(cbio1,0)或dpartPartGet(cbio1,1)返回的句柄,dpartPartGet要求使用位于CBIO to CBIO设备(dpartCbio)子层上的CBIO句柄,并把它定义为dosFs卷。
參数3表示在设备上能同一时候打开的文件数。
參数4表示是否在挂载卷时自己主动进行卷的完整性检測。
该函数在一个特定CBIO句柄相应的分区上创建dosFs文件系统,定义每一个磁盘卷的信息并将它们加入到I/O系统中。
图中此处用dosFsDevCreate(“/DOSA”,dpartPartGet(cbio1,
0),16,0)在第一个分区(dpartParGet中的參数0)安装文件系统,卷名为/DOSA。并在挂载时自己主动进行完整性检測。
2.5 格式化磁盘卷
使用dosFsVolFormat()函数将磁盘卷按dos格式格式化。该步骤仅仅能在磁盘卷第一次初始化时运行一次。假设DOS格式的磁盘卷已经被格式化,能够跳过此步。
dosFsVolFormat()的函数使用方法为:
STATUS dosFsVolFormat(void *device,intopt,FUNCPTR pPromptFunc)
參数1表示要运行格式化操作的卷名。
參数2表示格式化的选项。是比特映射。即选项的组合。0表示使用默认选项。
參考帮助;
參数3表示一个函数。该函数能够提示用户在格式化前改变卷的參数,0表示无函数;
函数返回格式化成功与否的状态值。图2中此处用dosFsVolFormat(“/DOSA”,0,0)将卷/DOSA格式化。
格式化后就能够使用了,能够用ll“/DOSA”挂载卷。此时可运行完整性检測,用dosFsShow “/DOSA”显示卷信息。
运行->devs会发现有/DOSA卷,运行->cd “/DOSA”将当前工作文件夹切换到该卷上。运行mkdir 文件夹名。在该卷上创建一个相应的文件夹。
运行rm 文件夹名,就可以删除相应文件夹。
有些函数里的CBIO句柄參数能够用BLK_DEV变量取代,此时系统会自己主动进行转换工作。
至此,磁盘设备上的文件系统创建完毕。用户能够直接訪问磁盘并进行相关操作。
推荐阅读
-
紧急模式问题处理 - 图 1 紧急模式 根本原因分析 应急模式提供了尽可能小的环境,即使无法进入应急模式,也可以在其中修复系统。在应急模式下,系统只安装根文件系统供读取,不尝试安装任何其他本地文件系统,不激活网络接口,只启动一些基本服务。 进入应急模式的原因通常是 /etc/fstab 文件中存在错误,导致文件系统挂载失败。 文件系统中存在错误,导致。 约束和限制 本节适用于 Linux 操作系统紧急模式。程序涉及修复文件系统。修复文件系统有丢失数据的风险,因此请先备份数据,然后再执行修复操作。 处理方法 输入根密码,然后进入修复模式。 在应急模式下,根分区以只读模式挂载。要修改根目录中的文件,需要执行以下命令以读写模式重新挂载根分区。# mount -o rw,remount / 请执行以下命令首先检查 fstab 文件是否有误,然后尝试挂载所有未挂载的文件系统。# mount -a 如果挂载点不存在,请创建一个挂载点。 如果不存在此类设备,请注释或删除挂载行。 如果指定了不正确的挂载选项,请将挂载参数更改为正确的参数。 如果没有发生错误,但出现 UNEXPECTED INCONSISTENCY;RUN fsck MANUALLY 消息(通常是由文件系统错误引起的),请跳至第 7 步。 执行以下命令打开 /etc/fstab 以修改相应的错误。# vi /etc/fstab /etc/fstab 文件包含以下字段,以空格分隔:[文件系统] [dir] [type] [options] [dump] [fsck] 表 1 /etc/fstab 参数 说明 参数 说明 [文件系统] 要挂载的分区或存储设备。 文件系统]列建议以 UUID 的形式写入。执行 blkid 命令可查询设备文件系统 UUID。 参考格式如下: # <device> <dir> <type> <options> <dump> <fsck>; UUID=b411dc99-f0a0-4c87-9e05-184977be8539 /home ext4 defaults 0 2 使用 UUID 的好处是,它们与磁盘顺序无关。如果你在 BIOS 中更改了存储设备的顺序,或重新插入了存储设备,或者因为某些 BIOS 可能会随机更改存储设备的顺序,那么使用 UUID 会更有效率。 [文件系统] 文件系统]的挂载位置。 类型 挂载设备或分区的文件系统类型,支持多种不同的文件系统:ext2、ext3、ext4、reiserfs、xfs、jfs、smbfs、iso9660、vfat、ntfs、swap 和 auto。 设置为自动类型后,挂载命令会猜测所使用的文件系统类型,这对 CDROM 和 DVD 等移动设备非常有用。 选项 挂载时要使用的参数,有些参数是特定文件系统特有的。例如,默认值参数使用文件系统的默认挂载参数,ext4 的默认参数为:rw、suid、dev、exec、auto、nouser、async。 有关更多参数,请执行以下命令查看 man 手册:# man mount
-
.NET高级面试指南 Topic XVIII [ 介绍外观模式(Appearance Pattern),该模式提供了一个隐藏系统复杂性的简化界面 ]。- 简化复杂系统:当系统具有复杂的子系统结构时,可以使用外观模式来简化界面。提供统一界面:当客户端需要访问多个子系统时,可以使用外观模式提供统一界面。 外观模式在现代软件开发中得到广泛应用,尤其是在复杂系统中。例如 图形用户界面库:许多图形用户界面库(如 Qt、GTK+ 等)都使用外观模式来隐藏底层的复杂性,并为开发人员提供简单的界面来创建用户界面。 操作系统接口:操作系统中的系统调用和应用程序接口通常也使用外观模式来隐藏底层硬件和系统的复杂性,为应用程序提供访问系统资源的简单接口。企业应用程序:在可能涉及多个子系统的大型企业应用程序中,外观模式可用于封装这些子系统,并为客户端提供统一的使用界面。 网络框架:许多网络框架(如 ASP.NET MVC、Spring MVC 等)也使用外观模式来隐藏底层的复杂性,并为开发人员提供简单的接口来处理 HTTP 请求和响应。 集成开发环境(IDE):集成开发环境通常包含代码编辑器、编译器、调试器等多种功能。外观模式可用于封装这些功能,并为开发人员提供开发软件的简单界面。 代码示例:
-
windows下进程间通信的(13种方法)-摘 要 本文讨论了进程间通信与应用程序间通信的含义及相应的实现技术,并对这些技术的原理、特性等进行了深入的分析和比较。 ---- 关键词 信号 管道 消息队列 共享存储段 信号灯 远程过程调用 Socket套接字 MQSeries 1 引言 ---- 进程间通信的主要目的是实现同一计算机系统内部的相互协作的进程之间的数据共享与信息交换,由于这些进程处于同一软件和硬件环境下,利用操作系统提供的的编程接口,用户可以方便地在程序中实现这种通信;应用程序间通信的主要目的是实现不同计算机系统中的相互协作的应用程序之间的数据共享与信息交换,由于应用程序分别运行在不同计算机系统中,它们之间要通过网络之间的协议才能实现数据共享与信息交换。进程间通信和应用程序间通信及相应的实现技术有许多相同之处,也各有自己的特色。即使是同一类型的通信也有多种的实现方法,以适应不同情况的需要。 ---- 为了充分认识和掌握这两种通信及相应的实现技术,本文将就以下几个方面对这两种通信进行深入的讨论:问题的由来、解决问题的策略和方法、每种方法的工作原理和实现、每种实现方法的特点和适用的范围等。 2 进程间的通信及其实现技术 ---- 用户提交给计算机的任务最终都是通过一个个的进程来完成的。在一组并发进程中的任何两个进程之间,如果都不存在公共变量,则称该组进程为不相交的。在不相交的进程组中,每个进程都独立于其它进程,它的运行环境与顺序程序一样,而且它的运行环境也不为别的进程所改变。运行的结果是确定的,不会发生与时间相关的错误。 ---- 但是,在实际中,并发进程的各个进程之间并不是完全互相独立的,它们之间往往存在着相互制约的关系。进程之间的相互制约关系表现为两种方式: ---- (1) 间接相互制约:共享CPU ---- (2) 直接相互制约:竞争和协作 ---- 竞争——进程对共享资源的竞争。为保证进程互斥地访问共享资源,各进程必须互斥地进入各自的临界段。 ---- 协作——进程之间交换数据。为完成一个共同任务而同时运行的一组进程称为同组进程,它们之间必须交换数据,以达到协作完成任务的目的,交换数据可以通知对方可以做某事或者委托对方做某事。 ---- 共享CPU问题由操作系统的进程调度来实现,进程间的竞争和协作由进程间的通信来完成。进程间的通信一般由操作系统提供编程接口,由程序员在程序中实现。UNIX在这个方面可以说最具特色,它提供了一整套进程间的数据共享与信息交换的处理方法——进程通信机制(IPC)。因此,我们就以UNIX为例来分析进程间通信的各种实现技术。 ---- 在UNIX中,文件(File)、信号(Signal)、无名管道(Unnamed Pipes)、有名管道(FIFOs)是传统IPC功能;新的IPC功能包括消息队列(Message queues)、共享存储段(Shared memory segment)和信号灯(Semapores)。 ---- (1) 信号 ---- 信号机制是UNIX为进程中断处理而设置的。它只是一组预定义的值,因此不能用于信息交换,仅用于进程中断控制。例如在发生浮点错、非法内存访问、执行无效指令、某些按键(如ctrl-c、del等)等都会产生一个信号,操作系统就会调用有关的系统调用或用户定义的处理过程来处理。 ---- 信号处理的系统调用是signal,调用形式是: ---- signal(signalno,action) ---- 其中,signalno是规定信号编号的值,action指明当特定的信号发生时所执行的动作。 ---- (2) 无名管道和有名管道 ---- 无名管道实际上是内存中的一个临时存储区,它由系统安全控制,并且独立于创建它的进程的内存区。管道对数据采用先进先出方式管理,并严格按顺序操作,例如不能对管道进行搜索,管道中的信息只能读一次。 ---- 无名管道只能用于两个相互协作的进程之间的通信,并且访问无名管道的进程必须有共同的祖先。 ---- 系统提供了许多标准管道库函数,如: pipe——打开一个可以读写的管道; close——关闭相应的管道; read——从管道中读取字符; write——向管道中写入字符; ---- 有名管道的操作和无名管道类似,不同的地方在于使用有名管道的进程不需要具有共同的祖先,其它进程,只要知道该管道的名字,就可以访问它。管道非常适合进程之间快速交换信息。 ---- (3) 消息队列(MQ) ---- 消息队列是内存中独立于生成它的进程的一段存储区,一旦创建消息队列,任何进程,只要具有正确的的访问权限,都可以访问消息队列,消息队列非常适合于在进程间交换短信息。 ---- 消息队列的每条消息由类型编号来分类,这样接收进程可以选择读取特定的消息类型——这一点与管道不同。消息队列在创建后将一直存在,直到使用msgctl系统调用或iqcrm -q命令删除它为止。 ---- 系统提供了许多有关创建、使用和管理消息队列的系统调用,如: ---- int msgget(key,flag)——创建一个具有flag权限的MQ及其相应的结构,并返回一个唯一的正整数msqid(MQ的标识符); ---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向队列中发送信息; ---- int msgrcv(msqid,cmd,buf)——从队列中接收信息; ---- int msgctl(msqid,cmd,buf)——对MQ的控制操作; ---- (4) 共享存储段(SM) ---- 共享存储段是主存的一部分,它由一个或多个独立的进程共享。各进程的数据段与共享存储段相关联,对每个进程来说,共享存储段有不同的虚拟地址。系统提供的有关SM的系统调用有: ---- int shmget(key,size,flag)——创建大小为size的SM段,其相应的数据结构名为key,并返回共享内存区的标识符shmid; ---- char shmat(shmid,address,flag)——将当前进程数据段的地址赋给shmget所返回的名为shmid的SM段; ---- int shmdr(address)——从进程地址空间删除SM段; ---- int shmctl (shmid,cmd,buf)——对SM的控制操作; ---- SM的大小只受主存限制,SM段的访问及进程间的信息交换可以通过同步读写来完成。同步通常由信号灯来实现。SM非常适合进程之间大量数据的共享。 ---- (5) 信号灯 ---- 在UNIX中,信号灯是一组进程共享的数据结构,当几个进程竞争同一资源时(文件、共享内存或消息队列等),它们的操作便由信号灯来同步,以防止互相干扰。 ---- 信号灯保证了某一时刻只有一个进程访问某一临界资源,所有请求该资源的其它进程都将被挂起,一旦该资源得到释放,系统才允许其它进程访问该资源。信号灯通常配对使用,以便实现资源的加锁和解锁。 ---- 进程间通信的实现技术的特点是:操作系统提供实现机制和编程接口,由用户在程序中实现,保证进程间可以进行快速的信息交换和大量数据的共享。但是,上述方式主要适合在同一台计算机系统内部的进程之间的通信。 3 应用程序间的通信及其实现技术 ---- 同进程之间的相互制约一样,不同的应用程序之间也存在竞争和协作的关系。UNIX操作系统也提供一些可用于应用程序之间实现数据共享与信息交换的编程接口,程序员可以通过自己编程来实现。如远程过程调用和基于TCP/IP协议的套接字(Socket)编程。但是,相对普通程序员来说,它们涉及的技术比较深,编程也比较复杂,实现起来困难较大。 ---- 于是,一种新的技术应运而生——通过将有关通信的细节完全掩盖在某个独立软件内部,即底层的通讯工作和相应的维护管理工作由该软件内部来实现,用户只需要将通信任务提交给该软件去完成,而不必理会它的具体工作过程——这就是所谓的中间件技术。 ---- 我们在这里分别讨论这三种常用的应用程序间通信的实现技术——远程过程调用、会话编程技术和MQSeries消息队列技术。其中远程过程调用和会话编程属于比较低级的方式,程序员参与的程度较深,而MQSeries消息队列则属于比较高级的方式,即中间件方式,程序员参与的程度较浅。 ---- 4.1 远程过程调用(RPC)
-
玩转Java底层:JMX详解 - jconsole与自定义MBean监控工具的实际应用与区别" 在日常JVM调优中,我们熟知的jconsole工具通过JMX包装的bean以图形化形式展示管理数据,而像jstat和jmap这类内建监控工具则由JVM直接支持。本文将以jconsole为例,深入讲解其实质——基于JMX的MBean功能,包括可视化界面上的bean属性查看和操作调用。 MBeans在jconsole中的体现是那些可观察的组件属性和方法,如上图所示,通过名为"Verbose"的属性能看到其值为false,同时还能直接操作该bean的方法,例如"closeJerryMBean"。 尽管jconsole给我们提供了直观的可视化界面,但请注意,这里的MBean并非固定不变,开发者可根据JMX提供的接口将自己的自定义bean展示到jconsole。以下步骤展示了如何创建并注册一个名为"StudyJavaMBean"的自定义MBean: 1. 首先定义接口`StudyJavaMBean`,接口需遵循MBean规范,即后缀为"MBean"且包含getter方法代表属性,如`getApplicationName`,和无返回值的setter方法代表操作,如`closeJerryMBean`。 ```java public interface StudyJavaMBean { String getApplicationName(); void closeJerryMBean(); } ``` 2. 编写接口的实现类`StudyJavaMBeanImpl`,实现接口中的方法: ```java public class StudyJavaMBeanImpl implements StudyJavaMBean { @Override public String getApplicationName() { return "每天学Java"; } @Override public void closeJerryMBean() { System.out.println("关闭Jerry应用"); } } ``` 3. 在代码中注册自定义MBean,涉及的关键步骤包括: - 获取平台MBeanServer - 定义ObjectName,指定唯一的MBean标识符 - 注册MBean到服务器 - 启动RMI连接器服务,以便jconsole能够访问 ```java public void registerMBean() throws Exception { // ... 具体实现省略 ... } ``` 实际运行注册后的MBean,您将在jconsole中发现并查看自定义bean的属性和调用相关方法。然而,这种方式相较于传统的属性/日志查看和HTTP接口,实用性相对有限,可能存在潜在的安全风险。但不可否认的是,JMX及其MBean机制对于获取操作系统信息、内存状态等关键性能指标仍然具有重要价值。例如: 1. **获取操作系统信息**:通过JMX MBean,可以直接获取到诸如CPU使用率、操作系统版本等系统级信息,这对于资源管理和优化工作具有显著帮助。
-
在Windows 7中使用U盘安装Ubuntu,轻松创建双操作系统
-
【Netty】「萌新入门」(七)ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的,这意味着它们可以快速地被分配和释放,但是也会产生一些开销。 直接内存需要手动分配和释放,因为它由操作系统管理,这使得分配和释放的速度更快,但是也需要更多的系统资源。 另外,直接内存可以映射到本地文件中,这对于需要频繁读写文件的应用程序非常有用。 此外,直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时,数据必须先从文件或网络中读取到堆内存中,然后再从堆内存中复制到直接缓冲区中,最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时,数据可以直接从文件或网络中读取到直接缓冲区中,并且可以直接从直接缓冲区中发送到网络中,避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf: ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf: ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意: 直接内存是一种特殊的内存分配方式,可以通过在堆外申请内存来避免 JVM 堆内存的限制,从而提高读写性能和降低 GC 压力。但是,直接内存的创建和销毁代价昂贵,因此需要慎重使用。 此外,由于直接内存不受 JVM 垃圾回收的管理,我们需要主动释放这部分内存,否则会造成内存泄漏。通常情况下,可以使用 ByteBuffer.clear 方法来释放直接内存中的数据,或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码: public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果: class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中,池化技术指的是通过对象池来重用已经创建的对象,从而避免了频繁地创建和销毁对象,这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options,来决定池化功能是否开启: -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后,非 Android 平台默认启用池化实现,Android 平台启用非池化实现; 这里我们使用非池化功能进行测试,依旧使用的是上面的测试代码 testCreateByteBuf,运行结果如下所示: class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到,ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf; 在没有池化的情况下,每次使用都需要创建新的 ByteBuf 实例,这个操作会涉及到内存的分配和初始化,如果是直接内存则代价更为昂贵,而且频繁的内存分配也可能导致内存碎片问题,增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销,并且重用池中的 ByteBuf 实例,减少了内存占用和内存碎片问题。另外,池化技术还可以采用类似 jemalloc 的内存分配算法,进一步提升分配效率。 在高并发环境下,池化技术的优点更加明显,因为内存的分配和释放都是比较耗时的操作,频繁的内存分配和释放会导致系统性能下降,甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中,从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时,需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现,包括堆内存(JVM 内存)实现 UnpooledHeapByteBuf 和堆外内存(直接内存)实现 UnpooledDirectByteBuf,以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf:通过 Java 的垃圾回收机制来自动回收内存; UnpooledDirectByteBuf:由于 JVM 的垃圾回收机制无法管理这些内存,因此需要手动调用 release 方法来释放内存; PooledByteBuf:使用了池化机制,需要更复杂的规则来回收内存; 由于池化技术的特殊性质,释放 PooledByteBuf 对象所使用的内存并不是立即被回收的,而是被放入一个内存池中,待下次分配内存时再次使用。因此,释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存,我们需要根据实际情况来设置池化技术的相关参数,以便及时回收内存; Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收,在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解; 每个 ByteBuf 对象被创建时,都会初始化为1,表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中,如果当前 handler 已经使用完该对象,需要通过调用 release 方法将计数减1,当计数为0时,底层内存会被回收,该对象也就被销毁了。此时即使 ByteBuf 对象还在,其各个方法均无法正常使用。 但是,如果当前 handler 还需要继续使用该对象,可以通过调用 retain 方法将计数加1,这样即使其他 handler 已经调用了 release 方法,该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说,应该尽可能地保证 retain 和 release 方法成对出现,以确保计数正确。
-
Linux设备驱动开发详解——学习笔记-设备驱动来联系。在没有操作系统的情况下,工程师可以根据硬件设备的特点自行定义接口。而在有操作系统的情况下,驱动的架构则由相应的操作系统来定义。驱动存在的意义就是给上层应用提供便利。 驱动针对的对象是存储器和外设。Linux将存储器和外设分为 3 个基础大类:字符设备、块设备、网络设备。 字符设备和块设备都被 Linux 映射到文件系统的文件和目录中,通过文件系统的接口(open、read、write、close等)来访问。其中,块设备可以通过类似 dd 命令对应的原始块设备来访问,也可以通过建立文件系统,以文件路径来访问。 学习 Linux 设备驱动,要求非常好的硬件基础、非常好的软件基础、一定的 Linux 内核基础和非常好的多任务并发控制和同步的基础。学习 Linux 设备驱动要将学习的函数、数据结构等放到整体架构中去理解,才能理清驱动中各组成部分之间的关系。 驱动设计的硬件基础 驱动工程师需要掌握 处理器、存储器、接口和总线、可编程门电路、原理图、硬件时序、芯片手册、仪器使用 等方面的内容。 处理器
-
在vxWorks操作系统中创建dosFs文件系统