通过运行时的本地、Locallow 和漫游 AppData 文件夹,实现快速访问和角色设置
%appdata%
表示windows的应用程序数据存储路径:C:\Users\用户名\AppData\Roaming
AppData 中的本地文件夹是什么?
Local文件夹主要包含与安装程序相关的文件夹。其中包含的数据 ( %localappdata%
) 无法随您的用户配置文件一起移动,因为它特定于 PC,因此太大而无法与服务器同步。例如,Internet Explorer 临时文件存储在Internet 临时文件或Cookies 文件夹下。此外,还有一个 Microsoft 文件夹,您可以在其中找到 Windows 活动的历史记录。
AppData 中的 LocalLow 文件夹是什么?
此 LocalLow 文件夹包含无法移动的数据。此外,它还具有较低级别的访问权限。例如,如果您在受保护或安全模式下运行 Web 浏览器,则应用程序将仅访问 LocalLow 文件夹中的数据。此外,LocalLow 文件夹不会在第二台计算机上创建。因此,访问 LocalLow 文件夹的任何应用程序都可能失败。
AppData 中的 Roaming 文件夹是什么?
Roaming 文件夹是一种可以轻松与服务器同步的文件夹。它的数据可以随着用户的个人资料从 PC 移动到 PC — 就像当您在域中时,您可以轻松登录到任何计算机并访问其收藏夹、文档等。例如,如果您登录到域中的另一台 PC,您的网络浏览器收藏夹或书签将可用。这是公司中漫游配置文件的主要优势之一。用户配置文件数据(复制到服务器),自定义数据始终可用,无论员工使用任何系统。
我可以删除 AppData LocalLow、Roaming 或 Local 文件夹中的所有内容吗?
您可以删除它们,但您可能会丢失程序设置。由于它们是受系统保护的文件夹,您可能需要启动到安全模式才能删除它们。
简而言之:
ProgramData文件夹包含非用户特定的全局应用程序数据,并且可供计算机上的所有用户使用。任何全局数据都放在这里。
AppData文件夹包含用户特定的首选项和配置文件配置,并进一步分为三个子文件夹:
漫游文件夹包含可以随用户配置文件从计算机移动到计算机的数据
本地文件夹包含无法随您的用户配置文件移动的数据。
LocalLow文件夹包括低级访问数据,例如。在受保护模式下运行时浏览器的临时文件。
C:\Windows\SystemApps是一个重要的系统文件夹,存放一些系统需要的动态链接库和驱动程序。
C:\ProgramData系统用户共享目录。XP系统的共享目录是C:\Documents and Settings\All Users\Application Data。从Vista开始,共享目录变为ProgramData。当用户进入C:\Users\All Users时,系统自动进入ProgramData目录。
C:\Users[username]\Documents某些软件(尤其是游戏),选择把软件配置信息存放在Documents下,便于用户找到使用它们(例如软件截图、音视频文件等)
Common Files是公有文件夹的意思,里面的文件以.dll居多,就是我们常说的动态连接库,也叫模块文件!简单来说就是不用启动某一软件,但是可以调用他的一个功能模块文件来实现特定功能.是不能删除的!是NT系统下的重要文件夹
system32是Windows 操作系统的系统文件夹,是操作系统的神经中枢,文件夹中包含了大量的用于Windows操作系统的文件。system32文件夹里主要用于存储 DLL 文件,控制面板小程序(.CPL), 设备驱动 (.drv),帮助文件 (.hlp 和 .cnt), MS-DOS 工具 (.com),语言支持文件 (.nls),屏幕保护 (.scr),安装信息文件 (.inf),以及其它用于支持、配置、或操作的文件。
Syswow64(Windows-on-Windows 64-bit)是一个Windows操作系统的子系统, 能够运行32-bit 应用 windows操作系统程序, 并且在所有的64-bit 版本的windows上都存在,包括:Windows 2000 Limited Edition Windows XP Professional x64 Edition,and IA-64 64-bit版本的Windows Server 2003 64-bit版本的Windows Vista 64-bit版本的Windows Server 2008 64-bit版本的Windows 7在Windows server 2008 R2上,这是一个可选组件。WoW64被设计用来处理许多在32-bit Windows 和64-bit Windows 之间的不同, 尤其是在Windows自身的结构变化上的不同。可以负责任的说syswow64是一个很重要的文件夹,你的64位win7旗舰版能运行32位的软件全靠它。
上一篇: 2023 年网络安全行业分布图
推荐阅读
-
通过运行时的本地、Locallow 和漫游 AppData 文件夹,实现快速访问和角色设置
-
【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 方法成对出现,以确保计数正确。