我的技术分享 👋🏼

概述 **大页内存(HugePages)**是通过大页内存来取代传统的4kb内存页面，使得管理虚拟地址数变少，加快了从虚拟地址到物理地址的映射，以及通过摒弃内存页面的换入换出，以提高内存的整体性能 对于大内存的管理(物理内存+虚拟内存)，大多数操作系统采用了分段或分页的方式进行管理 分段是粗粒度的管理方式，而分页则是细粒度的管理方式，分页方式可以避免内存空间的浪费 使用大页内存的好处： 减少TLB的失效情况 减少页表的内存消耗 减少缺页中断的次数 实现

总结一下结构体的写法： #include <stdio.h> #include <string.h> typedef struct package { int type; int len; char* data; } package; int main() { // 方式1 package pkg1; pkg1.type = 0; pkg1.len = 1; // 方式2 package pkg2; memcpy(&pkg2, &pkg1, sizeof(package)); // 方式3 package pkg3; pkg3 = pkg1; // 方式4 package pkg4; package* ptr = &pkg1; pkg4 = *ptr; return 0; } 其中方式1是比较常见的写法，单独为结构体赋值，方式2-4是将一个结构体完全赋值给另一个结构体，3属于是2的优化升级版 这里其实主要想记录的是方式4 package pkg4; package* ptr = &....

前言 最近在工作中碰到了哈希相关的事情，这里就简单探讨下哈希算法。 1.哈希表的长度为什么是素数 在哈希表中，我们需要用哈希表的长度作为除数进行模运算。对于素数而言，它的公因子只有1和它本身，因此使用素数取模时，可以保证取模结果尽量是平均分布的，即可以降低哈希冲突。 当然取模结果的分布情况跟被除数（hashkey）也有关系，但在hashkey相同的情况下，永远是素数比非素数的分布情况更好一些。因此哈希表的长度都为素数。 2.哈希算法 哈希算法有很多，针对不同的场景，不同类型（整型、字符型的hashkey，也有很多定制的哈希算法。目前最常用的、应用最广泛的字符型哈希算法是time33算法，其实就是针对每一个字符，不停✖️33，得到最终的hashkey。 time33算法的初始值是5381，为什么是5381呢？据说是经过验证后发现5381的分布情况会好一些。 整数型哈希算法一般都是根据实际场景需求来自己设置。比如两个key、三个key，应该如何设置乘数，调整位置，将其统一起来得到一个固定的、分布情况较好的哈希算法，降低哈希冲突。这些仍有待验证...

手续费 期货手续费是指期货交易者买卖期货成交后按成交合约总价值的一定比例所支付的费用。目前各期货交易所不同品种收取的手续费都不相同，一般是固定的n元一手，也有按固定比例收取的，通常为总成交额的万分之几。 总的来说，交易所手续费收取规则比较复杂，有各种减收、免收等政策，而且经常变。 申报费 申报费是指投资者在对期货和期权合约进行报单、撤单、询价等交易指令时所产生的费用 收取方式 对于具有实际控制关系的客户或非期货公司会员，根据申报费计算方法合并计算申报费，并按照实际控制关系账户组下各客户或非期货公司会员的信息量按比例确定相应的申报费 若客户或非期货公司会员隶属于多个实际控制关系账户组，则先计算其在各实际控制关系账户组下应付的申报费，最后按最大值原则确定其应付的申报费 对于同一客户在不同期货公司会员处开有多个交易编码的，按照客户在不同期货公司会员下产生的信息量按比例确定相应的申报费。 可以看到，申报费的收取方式也很复杂，同一客户有不同的情况，且客户下的不同类型的订单也有不同的处理方式

时间过得好快，一转眼，2022年就过去了。在今年的上半年，不管是生活还是博客，我都有好好的安排，可是进入五月份之后，情况突然就变了。可能是因为疫情，也可能是因为其他原因，突然就不想努力了，开始了长达半年的摆烂生活，仿佛一下子失去了人生目标。当然我也有在好好工作，可是却没了进取的心思，此时我才明白陪伴的力量，在人生路上有个伴是多么的好，当然我不是说现在的我的生活不好，只是终究会有些难以排解的心情，只能自己默默消化。 这一年，起初我的项目进展的是不太顺利了，做了两个多月的东西，需求突然更换，然后又重头开始，当然到现在来说，总体还算是顺利，其中离不开同事的包容与帮助。同时也让我感受到了自己与其他同事之间能力的差距，我的进步空间还很大，可是突然就摆烂了几个月... 应该是在六月份吧，还是七月份，我打球的时候受了一次挺严重的伤，当然那时我并没有当回事，因为之后打球什么的也感觉不到。可是伤病是逐渐累积的，它就在你一次一次的不以为然之中悄然给你爆发最大的伤害，终于我感觉到不对劲了，去医院检查了核磁共振后，才发现我的膝盖原来有这么多的毛病，医生告诉我不能再运动了，要彻底歇息好再考虑运动这件事，最好连楼....

正文 为了满足不同用户不同程度的优化需要，gcc提供了近百种优化选项，用来对编译时间，目标文件长度，执行效率这三方面进行不同的取舍和平衡。简单来说就是gcc提供了从O0-O3以及Os这几种不同的优化级别供用户选择，在这些选项中，包含了大部分有效的编译优化选项，并且可以在这个基础上，对某些选项进行屏蔽或添加，从而大大降低了使用的难度。下面围绕这几个不同级别的优化选项进行简单介绍 -O0：默认的编译选项，不做任何优化 -O和-O1：对程序做部分编译优化，对于大函数，优化编译占用稍微多的时间和相当大的内存。使用该选项，编译器会尝试减小生成代码的尺寸，以及缩短执行时间，但并不执行需要占用大量编译时间的优化。 -O2: 比 -O1更高级的选项，进行更多的优化。gcc将执行几乎所有的不包含时间和空间折中的优化。当设置O2选项时，编译器并不进行循环打开()loop unrolling以及函数内联。与O1比较而言，O2在优化增加了编译时间的基础上，提高了生成代码的执行效率。 -O3： 比O2更进一步的进行优化 -Os： 主要对程序的尺寸进行优化，打开了大部分O2优化中不会增加程序大小的优化选项，并对程....

正文 在Linux下抓包需要使用tcpdump命令，本文就主要对该命令进行一个简单的学习与总结。 简介 tcpdump是一个抓包工具。它能够监听、记录通过某一个主机进出的网络流量。并且可以保存到文件，或者再从文件读取抓下来的数据包。它保存下来的包也可以导入到wireshark里面，利用gui工具进行查看。当然非常重要的一点是，抓取的时候能够设置各种各样的过滤器，在海量数据里寻找有用信息。 使用 首先，使用tcpdump要使用root登录或者sudo权限，且在使用时如果不加任何参数，它会抓网络设备中第一个设备的包(不包括lo)，并且打印出每个包的简短信息。 -nn：tcpdump遇到协议号或者端口号时，不将这些号码转换成对应的协议名称或者端口名称。比如，21端口是FTP端口，我们希望直接显示21，而非FTP。 -x：告诉tcpdump命令，需要把协议头和包内容都原原本本的显示出来(tcpdump会以16进制和ASCII的形式显示)，这在进行协议分析时是绝对的利器。 -t：输出不打印时间戳 -c：设置抓取的包的个数 -s：限定包的大小，默认每个包存68bytes。加上-s选项，调整这个参....

正文 首先，编译程序时必须要加上-g参数。 简单总结一下GDB调试命令 gdb 可执行程序 // 使用调试模式 gdb 可执行程序 *.core // 进入调试模式，并查看错误信息 r/run // 运行程序 b/breakdown 文件名:行数 // 在某一行添加一个断点 p/print 变量名 // 打印变量值 watch 变量名 // 监控变量在程序运行过程中的变化 bt/backtrace // 查看栈帧信息 frame 帧号 // 进入指定栈帧 GDB(GNU Debugger)是UNIX及UNIX-like下的强大调试工具，可以调试ada,c,c++,asm,minimal,d,fortran.objective-c,go,java,pascal等语言。本文以C语言为例，介绍GDB启动调试的多种方式。 ### 启动调试 对于C程序来说，要想使程序可被调试，需要在编译时加上 **-g** 参数，保留调试信息，否则不能使用GDB进行调试，但如果不是自己编译的程序，并不知道是否带有-g参数，如何判断一个文件是否带有调试信息呢? 答：可以直接对该文件使用gdb命令，如 ```....

正文 cpp的STL并不是万能的，最近在使用STL时，发现list容器的size()方法和empty()方法的时间复杂度居然不一样，通过查阅资料发现，list中size()方法居然是对整个容器从头遍历一遍，empty()方法则是判断首尾两个指针是否相等。这样一来，在性能要求非常高的情况下，若要对list判空，则只能用empty()方法。 在网络通信过程中，性能并不完全取决于程序写的好坏，也与通信机器本身、是否绑定CPU核心、以及带宽有很大关系。在我对项目进行集成测试的时候，发现将系统部署在我的开发虚拟机上时，两个进程的通信速度就有瓶颈，而将机器部署在实际的测试机器上时，在一般速度下，这个瓶颈就自然消失了。 在记录一个坑，这个坑之前其实踩过一次了，但是我没有长记性，又踩了一次，这就是对指针取地址的这个操作了。 对于一个数组，若要对其进行操作，如memcpy，一般这样来做 char buffer[4096]; char name[30]; memcpy(name, buffer, sizeof(name)); memcpy(name, &buffer[0], sizeof(name....

前文 在实际项目开发过程中，经常会遇到一个目标文件需要使用不同目录下的源文件。如有个项目，构成如下所示: -base -base.cpp -base.h -src -makefile -%.cpp -%.h src目录下的源文件使用到了base库中的函数，因此在编译makefile时，需要用到base库，base库在另一个目录下，此时就需要使用混合编译的技巧。 正文 其实混合编译没什么技巧，只需要在编译时，将base库所在目录添加进makefile中即可。 CXXFALG = -m64 -Wall -std=c++11 BASE_PATH = ../base OBJS = $(BASE_PATH)/base.o test.o TARGET = test all:$(TARGET) @echo "Done everything successfully" $(TARGET): $(OBJS) $(CC) $(CXXFALG) -I $(BASE_PATH) $(OBJS) -o $(TARGET) %.o: %.cpp $(CC) -c $(CXXFALG) -I $(B....