本站迁移到[vanblog](https://vanblog.mereith.com/)，之前的评论已备份但近日博主非常忙碌导致无心迁移，待安置完全后便会迁移评论。

本站迁移到vanblog

由一次聊天引起的思考，也间接导致了我们项目一个奇怪的Bug。



# 起因

起因只是朋友在做作业的时候直呼运行缓慢，但仅将`Debug`模式更改为`Release`模式，运行效率却有了质的飞跃。这让我非常的疑惑，就本人一直以来的经验来看，无论如何两种模式效率都不可能差距如此之大，这让我产生了些许好奇。

![image-20230308205942788](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202303082059853.png)

![image-20230308210004516](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202303082100534.png)

这是视频：

Debug:

<div style="height: 0; padding-bottom: calc(100.00%); position:relative; width: 100%;"><iframe allow="autoplay; gyroscope;" allowfullscreen height="100%" referrerpolicy="strict-origin" src="https://www.kapwing.com/e/6408e51a099836001ecb813d" style="border:0; height:100%; left:0; overflow:hidden; position:absolute; top:0; width:100%" title="Embedded content made on Kapwing" width="100%"></iframe></div><p style="font-size: 12px; text-align: right;">Video edited on <a href="https://www.kapwing.com/video-editor">Kapwing</a></p>

Release:

<div style="height: 0; padding-bottom: calc(100.00%); position:relative; width: 100%;"><iframe allow="autoplay; gyroscope;" allowfullscreen height="100%" referrerpolicy="strict-origin" src="https://www.kapwing.com/e/6408f24e12e4750017f59d42" style="border:0; height:100%; left:0; overflow:hidden; position:absolute; top:0; width:100%" title="Embedded content made on Kapwing" width="100%"></iframe></div><p style="font-size: 12px; text-align: right;">Video edited on <a href="https://www.kapwing.com/video-editor">Kapwing</a></p>

# 答案

其实答案很简单，就是MSVC对于Debug模式链接了一套专门用于Debug的libc/runtime, 用于添加部分调试信息和一些编译器检查(比如典中典的边界检查)。

![image-20230308215811163](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202303082158192.png)

(因为没有Windows没法截libcd的图了，斯密马赛！)

简单的一些内存添加：(出自侯捷老师的课👀)

![image-20230308210907499](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202303082109281.png)

当然在Linux中是不存在其他libc的。一个libc走天下。

![image-20230308213750193](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202303082137259.png)

# Bug

其实本来到这里本篇文章就应该结束了，但正是因为SB至极的MSVC对于这两种模式的区分导致在遇到CMake的跨平台时候需要多对MSVC进行一步操作。

众所周知，`${CMAKE_CURRENT_BINARY_DIR}`能获取编译后文件的地址，可偏偏MSVC不走寻常路，下面又加了个文件夹Debug/Release，导致路径得单独判断。

顺便一提这个Debug和Release其实不是由`${CMAKE_BUILD_TYPE}`判断的，而是通过Toolchain里面选择Release或者Debug(是Toolchain决定type)，选的哪个`${CMAKE_BUILD_TYPE}`就会是哪个(仅限MSVC)。

为什么 MSVC Debug 模式如此慢

如何跟队友进行Git协同开发。



# 写在最前

本项目大多数

### 本地

操作都可以使用GUI完成，具体使用哪种GUI可自行选择：

[tortoisegit](https://tortoisegit.org/)

[Github Desktop](https://desktop.github.com/)

以及各种IDE自带Git(比如vscode，CLion，VS等均有附带)

具体使用教程可以自行B站搜索。本教程全程使用Terminal进行，主要操作可在GUI内搜索。

P.S. 其实本博客[第一篇文章](https://blog.fivezha.cn/post/14)就是讲Git的,不过那会的我实在是太菜了(虽然现在也很菜)，甚至部分图片也挂了(好不容易才找回来一部分)，所以不推荐看👀。

# Clone项目

首先你需要自己将Github中的项目Clone到自己本地当中，本教程以[TestRepository](https://github.com/TaixuEngineGroup/TestRepository)为示例：

首先先从Github仓库中复制链接：

![image-20230203193134374](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302031931418.png)

然后找一个你拿来存代码的文件夹，输入：

```shell
git clone git@github.com:TaixuEngineGroup/TestRepository.git
```

![image-20230203200222530](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032002555.png)

然后你就会发现多出来一个文件夹，此文件夹便是clone下来的远端仓库。

# 文件夹结构讲解

如果打开隐藏文件显示，可以看到`.git`文件夹，此文件夹储存了所有本地Git记录，如果删除了你本地Git记录和远程仓库连接都会消失，请慎重操作。

![image-20230203210255399](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032102427.png)

# 实现Feature

下面讲解如何实现一个功能并提交到项目中。

## 预先准备

首先先查看分支情况：

![image-20230203215503654](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032155684.png)

可以看到这里有两个分支，其中：

- main分支：用于固定发行版本commit的分支
- dev分支：实际开发合并的分支，所有功能需要合并到此分支中。

**禁止直接push到main和dev分支中务必使用pr**

**禁止直接push到main和dev分支中务必使用pr**

**禁止直接push到main和dev分支中务必使用pr**

关于原因可以参考：[为什么不能直接push到master分支？](https://liwt31.github.io/2019/09/01/nopush/)

如果dev或者main分支混乱绝对是地狱界别解决难度......

Clone下来的仓库默认是使用`main`分支的，如下图：

![git-tutorial](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032230650.png)

但是我们想要将其切换到dev分支，所以我们clone之后需要首先要在clone后的本地仓库内执行下面的指令：

```shell
git checkout dev
```

此时，分支便会切换：

![git-tutorial](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032235595.png)

此时我们已经正确设定好分支，可以开发了。

# 开发需求

**在开发分之前请务必进行pull操作！：**

```shell
git pull
```

我们假设有这么一个需求：

1. 在原有的test.cpp中添加”Helloworld”输出。
2. 在test.cpp中添加”404NotFound”输出

我们现在单独实现一个”HelloWorld”输出功能：

首先新建一个分支，分支名格式就是`需求编号-需求内容`，所以我们这个分支名就叫做`1-HelloWorldPrint`：

```shell
git branch 1-HelloWorldPrint
git checkout 1-HelloWorldPrint
```

![image-20230203232749179](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032327210.png)

此时便切换到`1-HelloWorldPrint`分支中了，然后在`test.cpp`中添加了HelloWorld字段：

![image-20230203233823976](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032338000.png)

添加完之后提交：

![image-20230203234112773](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032341795.png)

提交指令没有用过可以看B站的一些教程，比如[Git + GitHub 10分钟完全入门](https://www.bilibili.com/video/BV1KD4y1S7FL)(也可以看别人的，非推荐)。

然后就是推送到远程仓库中：

![image-20230203234748868](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302032347887.png)

上面两幅图都发生了两件事，一是在本地提交，二是推送到远程仓库，用图片来说就是下面两幅图：

![git-tutorial](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040000733.png)

Push则可以理解为将本地Git与远端Github同步：

![git-tutorial](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040001553.png)

之后开发完成之后在Github仓库中进行pullrequest操作，请求合并到dev分支中：

![image-20230204000612517](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040006542.png)

![image-20230204000753682](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040007704.png)

如果通过了且对自己代码有信心就可以直接merge了，不然就要找别人对你的代码进行code review。

![image-20230204001127930](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040011961.png)

Merge后请务必删除分支：

![image-20230204001557773](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040015794.png)

如果本地不需要更新/更改了请也删除分支：

![image-20230204001643111](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040016133.png)

## 冲突解决

事实上，分支合并有可能不会直接通过，会发生`conflict`，这时候就需要手动解决`conflict`，比如同时还有另外一位同学正在开发第二个`输出404NotFound`的功能，当他开发完成后进行正常push，准备合并的时候，此时系统就会提示有冲突，需要resolve。

![image-20230204002158143](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040021165.png)

![image-20230204002409353](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040024376.png)

![image-20230204002537452](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/202302040025475.png)

**注意：**

**解决conflict时，别人写的不一定是需要删的，有可能是别的需求，可以一起保留。如果看不出来在群里问。**

**解决conflict时，别人写的不一定是需要删的，有可能是别的需求，可以一起保留。如果看不出来在群里问。**

**解决conflict时，别人写的不一定是需要删的，有可能是别的需求，可以一起保留。如果看不出来在群里问。**

然后就可以merge了。

自此，一个简单的需求便完成了。

Git多人协作教程

本篇文章记录了我配了一个晚上作业环境的经过......



## 起因

其实并没有什么起因，只是单纯的讲师布置了作业让我们完成，第一步便是配置环境而已。

事情回到上午，A1 released，下载，解压，`code .`打开扫一眼，发现就只有一个QT环境，那环境岂不是轻松拿捏。但事实是我错了，晚上吃完饭开始搞，一直搞到凌晨，才成功运行。本文章就来记录一下晚上配置环境的经过。

## 噩梦的开始

通过阅读`readme.txt`，说明了QT版本为`5.13.0`并给出了下载地址。一顿安装后，启动`QT Creator`！打开`RaytraceRenderWindow.pro`，运行！报错！

What？怎么报错了？？仔细看看先......

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/originproblem.png)

hummmmmm，看上去像是clang不支持一个库，几经搜索得到了下面此噩耗。

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20221016203618.png)

当然，回复也给了解决方案：

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20221016203733.png)

啊哈，这不就安装一下完事儿了！

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/reinstall.png)

安装！链接！启动！报错！

What？？怎么又报错了？？？再仔细看看先......

奥，原来是没有链接上（这个时候我就应该意识到不对劲），我再单独链接一下咯，此时`.pro`文件已经由

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/original.png)

变为了

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/sec2.png)

编译！运行！报错！

为什么还是报错？？？我再再再看一下......

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/libarchwrong.png)

亏贼！`5.13.0`版本居然只有编译到`x86_64`版本的！而`brew`安装的只有编译为`arm64`的，所以根本没办法用！但是在下还是想到了两个解决方案：

- 将QT版本升级到有`arm64`的
- 自己编译一份`libopm`或者找找别人编译过的

有了大致方案，开干！

## 搞定！

### PlanA

首先测试第一种方案，将QT版本升级到6以上，再进行编译链接。

编译！报错！

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/openfind.png)

啊？又又又又报错了？定睛一看，阿西吧！怎么不支持OpenGL啊，只能寄希望于`PlanB`了。

### PlanB

啊！`PlanA`寄了，只能网上去搜索，翻了一页又一页谷歌，终于，功夫不负有心人，有一位大佬编译好了一份，并且支持arm和x86双架构([链接在此](https://mac.r-project.org/openmp/))！

下载！链接！编译！运行！成功！

终于！

![final](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/finalshow.png)

最后附上改完的`.pro`文件：

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/final.png)

```qmake
#adding openMP
unix:!macx {
    QMAKE_CXXFLAGS+= -fopenmp -Wall
    LIBS += -fopenmp
}

macx: {
    QMAKE_CXXFLAGS += -Xpreprocessor -fopenmp -lomp -I../libs/libomp/include
    QMAKE_LFLAGS += -lomp
    LIBS += -L../libs/libomp/lib

    # remove package time, accelerate the compile period
    CONFIG -= app_bundle
}
```

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20221016212910.png)

## 总结

此事让我感觉到了`MACOS`真的是多么的难用(当然也有`qmake`这种老旧`build system`的原因)，前年刚使用时觉得无比的好用，但是经历过这两年无数环境问题和配环境的痛苦，因为系统不开放而导致的很多妥协的方法，真的让我感觉到这个系统绝对是不适用于程序员的，让我怀念的反而是让我用了只有半年的`Linux`，随着`Electron`技术的发展，`Linux`系统的软件差距将会逐渐减少，终有一天，我还是会换回`Linux`。

记一次作业环境配置经历

本篇文章仅是简要记述我最近一次开服经历和我的MC回忆录。

现在的MC服务端真的是`小母牛戴胸罩——一套又一套`，感觉越来越麻烦了(？)

## 起因

相信2021年的合格网民应该都有个经常水的群吧，无论是游戏群还是宿舍群还是其他。没错，我也有一个这样的群，在前几天，群主迷上了[`RLCraft`](https://www.curseforge.com/minecraft/modpacks/rlcraft)这一个模组包，但是困于一个人玩不仅没意思，还觉得难，所以想和大家一起玩，正巧，本人有过开服(小服务器罢了)经历，所以这件事情便就由我这个半吊子程序员负责啦。



## 前期准备

### 服务器

找服务器算是这件事情还算是时间耗费比较少的了，稍微市场调研了一下，发现：

| 购买渠道                | 优点                                               | 缺点                                                         |
| ------------------- | ------------------------------------------------ | ---------------------------------------------------------- |
| 淘宝                  | 1.看上去主频比较高<br>2.看上去配置更符合MC服务器<br>3.有专门的人帮助你开服，维护 | 1.贵<br>2.不知道会不会跑路                                          |
| 闲鱼/淘宝某些利用特殊身份搞来的大厂云 | 1.学生机用习惯了各种操作都知道<br>2.看上去享有普通用户同等权力<br>3.性价比比较高  | 1.不知道号会不会收回<br>2.不知道账号来源<br>3.没有专门人员帮助你开服                  |
| 某些不知名小VPS厂商和国外厂     | 1.国外厂子不会出现我国特色网络问题<br>2.国内小厂看上去还算划算              | 1.国外厂延迟太高，消费高性价比低<br>2.国内小厂风评不好搜索，感觉像是在摸宝<br>3.没有专门的人帮助你开服 |

综合思考了一下，在`tb`找服务器大概最便宜钱也要在32元/月这个价位，优势基本在于高主频和专人维护，但是本人作为程序员，个人维护基本没有压力，而主频只是在大区块加载的时候才会体现出用途来(本服务器没有红石卡服人所以不用想这种问题)，所以果断闲鱼见了。

拿下了服务器，其实事情就简单了，之后就是一套装系统，改SSH端口和验证，装JDK，搞点交换内存等等操作。

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20220110011737.png)

### 服务端

在开始写正式部分之前，我想先追忆一下我N年前的开服经历。

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/QQ20220103-0.jpg)

这是我第一次（其实并不是第一次，只不过是这次发了说说）尝试自己搭建MC服务器发的说说，当时是在`2014`年，还在上初中的我正沉迷于MC自由的世界中，每天沉迷于大佬们制作的地图当中，但可惜一个人玩太没有意思，所以我便拉了几位朋友入坑MC，一起玩美滋滋。

在我印象中，基本上开服就那么几款，想要纯净就用官方端，如果想要插件就用水桶端，如果想玩mod服，额，我忘了(?)，貌似当时就有官方Forge端来着，好像大家都不用。总之在我印象中开服是一件很简单只用几个命令就搞定的事情，但这个模组包却耗费了我一些时间。

首先`server pack`是官方给的，但是！他没有给服务端软件啊！就相当于我抱着一堆的配置文件在这里想着怎么开服，这么多年过去了，我怎么能知道现版本怎么开啊！

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20220110013629.png)

看了下原帖，好家伙，原来作者是怕给大家服务端导致大家都自己开服而不用合(qia)作(qian)方的服务器了啊！

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20220110015009.png)

不过这能难得到我？几经搜索过后，我便从国内搬运帖中找到了搬运者给出的建议，哈哈哈哈！服务端来咯~ 这开服，多是一件美事啊！

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20220110014927.png)

## 开服！

下载完毕，然后满心欢喜打开文件，然后......

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20220110023846.png)

呃呃，怎么回事？查了半天文档才发现这个`Sponge Forge`核心是以`Mod`的形式挂载到官方`Forge`端的，而这个`Forge`端又是需要下载`Forge Installer`对于官方端进行的补丁。

![](https://cdn.jsdelivr.net/gh/xmmmmmovo/ResourcesBackup/blog/20220110025139.png)

搞完这一套，我只想说：太！复！杂！了！吧！这种事情不应该封装成一个`.jar`文件搞定吗，还搞这种套娃行为，太麻烦了。

不过最终还是搞定了。

### 调优

在游玩的过程中我发现有时候内存会飙升，有时甚至在左下角提示内存过载的现象，针对此现象，稍微优化了服务端一下。

首先是`JDK/JRE`则换成了阿里的[dragonwell8](https://github.com/alibaba/dragonwell8)，据说CPU利用效率很不错。

然后就是`GC`算法换成比较新的`G1`GC，关闭默认GC，把内存直接开满，减少GC时间，增大新生代数量适应快速区块加载......懒，自己看吧。

```shell
../jdk8u312-b01/bin/java
 -Xmx4G
 -Xms3G
 -XX:+UseG1GC
 -XX:+UnlockExperimentalVMOptions
 -XX:MaxGCPauseMillis=100
 -XX:+DisableExplicitGC
 -XX:TargetSurvivorRatio=90
 -XX:G1NewSizePercent=50
 -XX:G1MaxNewSizePercent=80
 -XX:G1MixedGCLiveThresholdPercent=35
 -XX:+AlwaysPreTouch
 -XX:+ParallelRefProcEnabled
 -XX:-UseAdaptiveSizePolicy
 -Xmn128M 
 -XX:+AggressiveOpts
 -XX:+UseCompressedOops
 -Dlog4j.configurationFile=log4j2_112-116.xml
 -jar forge-1.12.2-14.23.5.2860.jar
```

`log4j`漏洞解决方案来自[Important Message: Security vulnerability in Java Edition | Minecraft](https://www.minecraft.net/en-us/article/important-message--security-vulnerability-java-edition)

### 愉快的游玩

然后就是和朋友一起玩啦，不过这个模组包真的好难好难好难......

## 结语

伴随着2022年的新年钟声敲响，正在写这篇博客的我已经悄然步入了2022年，看着大家空间或者朋友圈里面的各种炫耀或者秀恩爱，好像就我一个人在这里调试服务器一样，突然感觉好孤独。

孤独的同时我又回想起幼时的我，水狼的牧场物语，丧魂村，还有经典的索尼亚斯大陆，这些有趣耐玩的地图给了我一个快乐的童年(?)。还记得当年沉迷[D大的直播帖](https://tieba.baidu.com/p/1766018024)，里面各种自动化的操作让我震惊。还有[12dora](https://space.bilibili.com/70093)的视频，让我觉得原来跟朋友玩这么有趣，我才有了开服的想法。

我认为MC这款游戏已经不需要再安利了，至少现如今大家都会玩过这么一款初看画质极其糟糕，但是却又充满魔性的游戏。还是希望MC这款游戏仍能够这样迸发活力，至少这个游戏真的是我的童年。