欢迎来到【庄家筹码量公式源码】【手机波形显示源码】【csdn下载系统源码】dnf e源码-皮皮网网站!!!

皮皮网

【庄家筹码量公式源码】【手机波形显示源码】【csdn下载系统源码】dnf e源码-皮皮网 扫描左侧二维码访问本站手机端

【庄家筹码量公式源码】【手机波形显示源码】【csdn下载系统源码】dnf e源码

2024-11-26 16:30:00 来源:{typename type="name"/} 分类:{typename type="name"/}

1.redis和memcached的区别
2.玩了CF结束游戏 再登陆DNF 再DNF退出游戏 电脑基本都会蓝屏 蓝屏代码00000076
3.带源码怎样弄进易语言

dnf e源码

redis和memcached的区别

       Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较:

       1、Redis支持服务器端的数据操作:Redis相比Memcached来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在Memcached里,你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中,这些复杂的操作通常和一般的GET/SET一样高效。所以,如果需要缓存能够支持更复杂的结构和操作,那么Redis会是不错的选择。

       2、内存使用效率对比:使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,由于其组合式的压缩,其内存利用率会高于Memcached。

       3、性能对比:由于Redis只使用单核,而Memcached可以使用多核,所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起Memcached,还是稍有逊色。

       å…·ä½“为什么会出现上面的结论,以下为收集到的资料:

       1、数据类型支持不同

       ä¸ŽMemcached仅支持简单的key-value结构的数据记录不同,Redis支持的数据类型要丰富得多。最为常用的数据类型主要由五种:String、Hash、List、Set和Sorted Set。Redis内部使用一个redisObject对象来表示所有的key和value。redisObject最主要的信息如图所示:

       type代表一个value对象具体是何种数据类型,encoding是不同数据类型在redis内部的存储方式,比如:type=string代表value存储的是一个普通字符串,那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的,当然前提是这个字符串本身可以用数值表示,比如:”″ “”这样的字符串。只有打开了Redis的虚拟内存功能,vm字段字段才会真正的分配内存,该功能默认是关闭状态的。

       1)String

       å¸¸ç”¨å‘½ä»¤ï¼šset/get/decr/incr/mget等;

       åº”用场景:String是最常用的一种数据类型,普通的key/value存储都可以归为此类;

       å®žçŽ°æ–¹å¼ï¼šString在redis内部存储默认就是一个字符串,被redisObject所引用,当遇到incr、decr等操作时会转成数值型进行计算,此时redisObject的encoding字段为int。

       2)Hash

       å¸¸ç”¨å‘½ä»¤ï¼šhget/hset/hgetall等

       åº”用场景:我们要存储一个用户信息对象数据,其中包括用户ID、用户姓名、年龄和生日,通过用户ID我们希望获取该用户的姓名或者年龄或者生日;

       å®žçŽ°æ–¹å¼ï¼šRedis的Hash实际是内部存储的Value为一个HashMap,并提供了直接存取这个Map成员的接口。如图所示,Key是用户ID,源码 value是一个Map。这个Map的key是成员的属性名,value是属性值。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。当前HashMap的实现有两种方式:当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储,而不会采用真正的HashMap结构,这时对应的value的redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

       3)List

       å¸¸ç”¨å‘½ä»¤ï¼šlpush/rpush/lpop/rpop/lrange等;

       åº”用场景:Redis list的应用场景非常多,也是Redis最重要的数据结构之一,比如twitter的关注列表,粉丝列表等都可以用Redis的list结构来实现;

       å®žçŽ°æ–¹å¼ï¼šRedis list的实现为一个双向链表,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销,Redis内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。

       4)Set

       å¸¸ç”¨å‘½ä»¤ï¼šsadd/spop/smembers/sunion等;

       åº”用场景:Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的;

       å®žçŽ°æ–¹å¼ï¼šset 的内部实现是一个 value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。

       5)Sorted Set

       å¸¸ç”¨å‘½ä»¤ï¼šzadd/zrange/zrem/zcard等;

       åº”用场景:Redis sorted set的使用场景与set类似,区别是set不是自动有序的,而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序,并且是插入有序的,即自动排序。当你需要一个有序的并且不重复的集合列表,那么可以选择sorted set数据结构,比如twitter 的public timeline可以以发表时间作为score来存储,这样获取时就是自动按时间排好序的。

       å®žçŽ°æ–¹å¼ï¼šRedis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。

       2、内存管理机制不同

       åœ¨Redis中,并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。当物理内存用完时,Redis可以将一些很久没用到的value交换到磁盘。Redis只会缓存所有的key的信息,如果Redis发现内存的使用量超过了某一个阀值,将触发swap的操作,Redis根据“swappability = age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中,同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。当然,机器本身的内存必须要能够保持所有的key,毕竟这些数据是不会进行swap操作的。同时由于Redis将内存中的数据swap到磁盘中的时候,提供服务的主线程和进行swap操作的子线程会共享这部分内存,所以如果更新需要swap的数据,Redis将阻塞这个操作,直到子线程完成swap操作后才可以进行修改。当从Redis中读取数据的时候,如果读取的key对应的value不在内存中,那么Redis就需要从swap文件中加载相应数据,然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下,Redis会出现阻塞,即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小,进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中,这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小,对需要从swap文件中加载相应数据的读取请求进行并发操作,减少阻塞的时间。

       å¯¹äºŽåƒRedis和Memcached这种基于内存的数据库系统来说,内存管理的效率高低是影响系统性能的关键因素。传统C语言中的malloc/free函数是最常用的分配和释放内存的方法,但是这种方法存在着很大的缺陷:首先,对于开发人员来说不匹配的malloc和free容易造成内存泄露;其次频繁调用会造成大量内存碎片无法回收重新利用,降低内存利用率;最后作为系统调用,其系统开销远远大于一般函数调用。所以,为了提高内存的管理效率,高效的内存管理方案都不会直接使用malloc/free调用。Redis和Memcached均使用了自身设计的内存管理机制,但是实现方法存在很大的差异,下面将会对两者的内存管理机制分别进行介绍。

       Memcached默认使用Slab Allocation机制管理内存,其主要思想是按照预先规定的大小,将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录,以完全解决内存碎片问题。Slab Allocation机制只为存储外部数据而设计,也就是说所有的key-value数据都存储在Slab Allocation系统里,而Memcached的其它内存请求则通过普通的malloc/free来申请,因为这些请求的数量和频率决定了它们不会对整个系统的性能造成影响Slab Allocation的原理相当简单。 如图所示,它首先从操作系统申请一大块内存,并将其分割成各种尺寸的块Chunk,并把尺寸相同的块分成组Slab Class。其中,Chunk就是用来存储key-value数据的最小单位。每个Slab Class的大小,可以在Memcached启动的时候通过制定Growth Factor来控制。假定图中Growth Factor的取值为1.,如果第一组Chunk的大小为个字节,第二组Chunk的大小就为个字节,依此类推。

       å½“Memcached接收到客户端发送过来的数据时首先会根据收到数据的大小选择一个最合适的Slab Class,然后通过查询Memcached保存着的该Slab Class内空闲Chunk的列表就可以找到一个可用于存储数据的Chunk。当一条数据库过期或者丢弃时,该记录所占用的Chunk就可以回收,重新添加到空闲列表中。从以上过程我们可以看出Memcached的内存管理制效率高,而且不会造成内存碎片,但是它最大的缺点就是会导致空间浪费。因为每个Chunk都分配了特定长度的内存空间,所以变长数据无法充分利用这些空间。如图 所示,将个字节的数据缓存到个字节的Chunk中,剩余的个字节就浪费掉了。

       Redis的内存管理主要通过源码中zmalloc.h和zmalloc.c两个文件来实现的。Redis为了方便内存的管理,在分配一块内存之后,会将这块内存的大小存入内存块的头部。如图所示,real_ptr是redis调用malloc后返回的指针。redis将内存块的大小size存入头部,size所占据的内存大小是已知的,为size_t类型的长度,然后返回ret_ptr。当需要释放内存的时候,ret_ptr被传给内存管理程序。通过ret_ptr,程序可以很容易的算出real_ptr的值,然后将real_ptr传给free释放内存。

       Redis通过定义一个数组来记录所有的内存分配情况,这个数组的长度为ZMALLOC_MAX_ALLOC_STAT。数组的每一个元素代表当前程序所分配的内存块的个数,且内存块的大小为该元素的下标。在源码中,这个数组为zmalloc_allocations。zmalloc_allocations[]代表已经分配的长度为bytes的内存块的个数。zmalloc.c中有一个静态变量used_memory用来记录当前分配的内存总大小。所以,总的来看,Redis采用的是包装的mallc/free,相较于Memcached的内存管理方法来说,要简单很多。

       3、数据持久化支持

       Redis虽然是基于内存的存储系统,但是它本身是支持内存数据的持久化的,而且提供两种主要的持久化策略:RDB快照和AOF日志。而memcached是不支持数据持久化操作的。

       1)RDB快照

       Redis支持将当前数据的快照存成一个数据文件的持久化机制,即RDB快照。但是一个持续写入的数据库如何生成快照呢?Redis借助了fork命令的copy on write机制。在生成快照时,将当前进程fork出一个子进程,然后在子进程中循环所有的数据,将数据写成为RDB文件。我们可以通过Redis的save指令来配置RDB快照生成的时机,比如配置分钟就生成快照,也可以配置有次写入就生成快照,也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中,你也可以通过Redis的CONFIG SET命令在Redis运行时设置规则,不需要重启Redis。

       Redis的RDB文件不会坏掉,因为其写操作是在一个新进程中进行的,当生成一个新的RDB文件时,Redis生成的子进程会先将数据写到一个临时文件中,然后通过原子性rename系统调用将临时文件重命名为RDB文件,这样在任何时候出现故障,Redis的RDB文件都总是可用的。同时,Redis的RDB文件也是Redis主从同步内部实现中的一环。RDB有他的不足,就是一旦数据库出现问题,那么我们的RDB文件中保存的数据并不是全新的,从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下,这是可以忍受的。

       2)AOF日志

       AOF日志的全称是append only file,它是一个追加写入的日志文件。与一般数据库的binlog不同的是,AOF文件是可识别的纯文本,它的内容就是一个个的Redis标准命令。只有那些会导致数据发生修改的命令才会追加到AOF文件。每一条修改数据的命令都生成一条日志,AOF文件会越来越大,所以Redis又提供了一个功能,叫做AOF rewrite。其功能就是重新生成一份AOF文件,新的AOF文件中一条记录的操作只会有一次,而不像一份老文件那样,可能记录了对同一个值的多次操作。其生成过程和RDB类似,也是fork一个进程,直接遍历数据,写入新的AOF临时文件。在写入新文件的过程中,所有的写操作日志还是会写到原来老的AOF文件中,同时还会记录在内存缓冲区中。当重完操作完成后,会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的AOF文件取代老的AOF文件。

       AOF是一个写文件操作,其目的是将操作日志写到磁盘上,所以它也同样会遇到我们上面说的写操作的流程。在Redis中对AOF调用write写入后,通过appendfsync选项来控制调用fsync将其写到磁盘上的时间,下面appendfsync的三个设置项,安全强度逐渐变强。

       appendfsync no 当设置appendfsync为no的时候,Redis不会主动调用fsync去将AOF日志内容同步到磁盘,所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统,是每秒进行一次fsync,将缓冲区中的数据写到磁盘上。

       appendfsync everysec 当设置appendfsync为everysec的时候,Redis会默认每隔一秒进行一次fsync调用,将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略,再等一秒钟。也就是在两秒后再进行fsync,这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞,所以当前的写操作就会阻塞。所以结论就是,在绝大多数情况下,Redis会每隔一秒进行一次fsync。在最坏的情况下,两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit,就是组合多次写操作的数据,一次性将日志写到磁盘。

       appednfsync always 当设置appendfsync为always时,每一次写操作都会调用一次fsync,这时数据是最安全的,当然,由于每次都会执行fsync,所以其性能也会受到影响。

       å¯¹äºŽä¸€èˆ¬æ€§çš„业务需求,建议使用RDB的方式进行持久化,原因是RDB的开销并相比AOF日志要低很多,对于那些无法忍数据丢失的应用,建议使用AOF日志。

       4、集群管理的不同

       Memcached是全内存的数据缓冲系统,Redis虽然支持数据的持久化,但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说,机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小,就需要构建分布式集群来扩展存储能力。

       Memcached本身并不支持分布式,因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。下图给出了Memcached的分布式存储实现架构。当客户端向Memcached集群发送数据之前,首先会通过内置的分布式算法计算出该条数据的目标节点,然后数据会直接发送到该节点上存储。但客户端查询数据时,同样要计算出查询数据所在的节点,然后直接向该节点发送查询请求以获取数据。

       ç›¸è¾ƒäºŽMemcached只能采用客户端实现分布式存储,Redis更偏向于在服务器端构建分布式存储。最新版本的Redis已经支持了分布式存储功能。Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本,它没有中心节点,具有线性可伸缩的功能。下图给出Redis Cluster的分布式存储架构,其中节点与节点之间通过二进制协议进行通信,节点与客户端之间通过ascii协议进行通信。在数据的放置策略上,Redis Cluster将整个key的数值域分成个哈希槽,每个节点上可以存储一个或多个哈希槽,也就是说当前Redis Cluster支持的最大节点数就是。Redis Cluster使用的分布式算法也很简单:crc( key ) % HASH_SLOTS_NUMBER。

       ä¸ºäº†ä¿è¯å•ç‚¹æ•…障下的数据可用性,Redis Cluster引入了Master节点和Slave节点。在Redis Cluster中,每个Master节点都会有对应的两个用于冗余的Slave节点。这样在整个集群中,任意两个节点的宕机都不会导致数据的不可用。当Master节点退出后,集群会自动选择一个Slave节点成为新的Master节点。

玩了CF结束游戏 再登陆DNF 再DNF退出游戏 电脑基本都会蓝屏 蓝屏代码

       1、虚拟内存不足造成系统多任务运算错误

       虚拟内存是源码WINDOWS系统所特有的一种解决系统资源不足的方法,其一般要求主引导区的源码硬盘剩余空间是其物理内存的2-3倍。而一些发烧友为了充分利用空间,源码将自己的源码硬盘塞到满满的,忙记了WINDOWS这个苛刻的源码庄家筹码量公式源码要求。结果导致虚拟内存因硬盘空间不足而出现运算错误,源码所以就出现蓝屏。源码要解决这个问题好简单,源码尽量不要把硬盘塞得满满的源码,要经常删除一些系统产生的源码临时文件、交换文件,源码从而可以释放空间。源码或可以手动配置虚拟内存,源码选择高级,源码把虚拟内存的默认地址,转到其他的逻辑盘下。这样就可以避免了因虚拟内存不足而引起的蓝屏。

       2、手机波形显示源码CPU超频导致运算错误

       超频对于发烧友来说是常事,所以由超频所引起的各种故障也就在所难免了。超频,就本身而言就是在原有的基础上完成更高的性能,但由于进行了超载运算,造成其内部运算过多,使CPU过热,从而导致系统运算错误。有些CPU的超频性能比较好,如INTEL的赛扬处理器和AMD-K6-2处理器还算较好的,但有时也会出现一些莫名其妙的错误。(例如:我曾试过将INTEL赛扬A,在超频到时,软驱在没有接受命令时,进行读盘操作)。 INTEL的低于的CPU以及AMD-K5的超频能力就不是那么好。建议高档的CPU要超频时,那么散热工作一定要做好,csdn下载系统源码最好装一个大的风扇,再加上一些硅胶之类的散热材料。至于一些低档的CPU我建议你就最好不要超频了,免得超频达不到预想的效果反而经常出现蓝屏影响计算机的正常速度。

       二、内存条的互不兼容或损坏引起运算错误

       这时个最直观的现象,因为这个现象往往在一开机的时候就可以见到,根本启动不了计算机,画面提示出内存有问题,问你是否要继续。造成这种错误是物理上的损坏内存或者内存与其它硬件不兼容所致。这时候只有换过另外的内存了。

       三、光驱在读盘时被非正常打开所至

       这个现象是在光驱正在读取数据时,由于被误操作打开而导致出现蓝屏。这个问题不影响系统正常动作,只要再弹入光盘或按ESC键就可以。

       以上是原神源码搭建我在维护计算机中碰到导致蓝屏的几种原因,或许还会有其他一些莫名其妙的问题导致计算机出现蓝屏。不管怎样,遇到这类问题后,应先仔细分析问题发生的原因,然后再着手解决。

       四、硬件剩余空间太小或碎片太多

       由于Win9X运行时需要用硬盘作虚拟内存,这就要求硬盘必须保留一定的自由空间以保证程序的正常运行。一般而言,最低应保证MB以上的空间,否则出现“蓝屏”很可能与硬盘剩余空间太小有关。另外,硬盘的碎片太多,也容易导致“蓝屏”的出现。因此,每隔一段时间进行一次碎片整理是必要的。

       五、系统硬件冲突

       这种现象导致“蓝屏”也比较常见。e chart源码解析实践中经常遇到的是声卡或显示卡的设置冲突。在“控制面板”→“系统”→“设备管理”中检查是否存在带有**问号或感叹号的设备,如存在可试着先将其删除,并重新启动电脑,由Win9X自动调整,一般可以解决问题。若还不行,可手工进行调整或升级相应的驱动程序。

       "蓝屏"的软件原因及解决

       与硬件密切联系的是软件,有时软件在"蓝屏"现象中也"功不可没",加载了过多的程序、注册表有问题、软硬不兼容、驱动程序有问题,相对于硬件原因来说要不易察觉些,可要多加注意.........

       一、启动时加载程序过多

       不要在启动时加载过多的应用程序(尤其是你的内存小于MB),以免使系统资源消耗殆尽。正常情况下,Win9X启动后系统资源应不低于%。最好维持在%以上,若启动后未运行任何程序就低于%,就需要卸掉一部分应用程序,否则就可能出现“蓝屏”。

       二、应用程序存在着BUG

       有些应用程序设计上存在着缺陷或错误,运行时有可能与Win9X发生冲突或争夺资源,造成Win9X无法为其分配内存地址或遇到其保护性错误。这种BUG可能是无法预知的,免费软件最为常见。另外,由于一些用户还在使用盗版软件(包括盗版Win9X),这些盗版软件在解密过程中会破坏和丢失部分源代码,使软件十分不稳定,不可靠,也常常导致“蓝屏”。

       三、遭到不明的程序或病毒攻击所至

       这个现象只要是平时我们在上网的时候遇到的,当我们在冲浪的时候,特别是进到一些BBS站时,可能暴露了自己的IP,被"黑客"用一些软件攻击所至。对互这种情况最好就是在自己的计算机上安装一些防御软件。再有就是登录BBS要进行安全设置,隐藏自己IP。

       四、版本冲突

       有些应用程序需调用特定版本的动态链接库DLL,如果在安装软件时,旧版本的DLL覆盖了新版本的DLL,或者删除应用程序时,误删了有用的DLL文件,就可能使上述调用失败,从而出现“蓝屏”。不妨重新安装试一试。

       五、注册表中存在错误或损坏

       很多情况下这是出现“蓝屏”的主要原因。注册表保存着Win9X的硬件配置、应用程序设置和用户资料等重要数据,如果注册表出现错误或被损坏,就很可能出现“蓝屏”。如果你的电脑经常出现“蓝屏”,你首先就应考虑是注册表出现了问题,应及时对其检测、修复,避免更大的损失。

       六、软硬件不兼容

       新技术、新硬件的发展很快,如果安装了新的硬件常常出现“蓝屏”,那多半与主板的BIOS或驱动程序太旧有关,以致不能很好支持硬件。如果你的主板支持BIOS升级,应尽快升级到最新版本或安装最新的设备驱动程序。

       Windows "蓝屏"分析与解决篇

       Win也许可以说得上是一个划时代的操作系统,但是它仍然不能够避免蓝屏死机(Blue Screen of Death)问题,Win的"蓝屏"(BSOD)和NT4以前的"蓝屏"消息是完全不同的。最大的不同就是NT中的BSOD只包含一个通用的停止消息类型(就是实际的出错代码), 但是Win的BSOD包含有两种消息类型:停止消息和硬件消息。停止消息是指,当win的内核发现一个它不能够恢复的软件错误时候产生的错误消息,它分为:常规停止消息、安装停止消息、可执行程序安装停止消息、软件陷阱停止消息四种类型......针对Windows的蓝屏,在上述概括的现象与对策基础上,我们分两方面来分析:

       Windows 中蓝屏死机之停止信息分析

       简介:什么是蓝屏死机(BSOD)问题?

       BSOD就是显示在蓝色屏幕背景下的出错信息。一般这种出错信息严重到你的整个操作系统当机,你只有重新冷启动的选择。

       刨析BSOD

       BSOD可以分成独立的几部分,每部分包含有有价值的错误处理信息。这几部分包括:

       1、bug检查部分:这是BSOD中包含实际出错消息的位置。在这部分中,你应该注意的是出错代码(就是在单词“Stop”后面的十六进制数字)和错误符号(就是紧跟在出错代码后的单词)

       2、推荐用户采取行动部分:这部分经常包含一些一般的指导你如何纠正错误的步骤的消息。

       3、调试端口信息部分:这部分包含有你应该如何设置你的内核调试器的信息。内核调试器是让你可以通过手工连接到计算机并对进程进行调试的工具。

带源码怎样弄进易语言

       打开易语言 单击新建 -- 选择window窗口程序--此时出现一个窗口 双击进入代码编写区域 然后将 子程序名框 选中 删除

       将你的代码 粘贴进入 ~

       注:楼主的代码要是 用的附带的模块 还要自己在 左边的模块引用表里添加

       希望回答对楼主有帮助 O(∩_∩)O~