散列算法从两个方面来看，一是散列函数的构造，二是冲突的解决方法。散列函数的优劣主要参考因素是装填因子；

散列函数的构造

1. 除整留余法， 此方法的核心是找到一个素数作为数组的长度，并且构造的算法为hash(key) = key % M( M 是素数)
   • 优点：简单，易于构造。
   • 不足：1.）hash(0) 恒等于0，具有不变的项。显然违背了 hash 的要义，随机性不好。2.） 此外，用取余的方法键之间的存在线性的联系，也没有一个好的随机性。
2. MAD，hash(key) = (a*key + b) % M
3. 数字分析法，此方法抽取 key 中的某几位来作为地址。优势也是简单。但缺点是只取几位作为参考，与其他未被取到的值没有产生联系。
4. 折叠法，将数字分成几组，并把每组相加的和作为地址。
5. 伪随机法，该方法确实方便快捷而且也满足随机性。但问题在于伪随机数的生成方法存在移植性问题。因此使用时也需谨慎。

要说死锁，先明确一个「资源」的概念。进程对设备，文件等取得独占性访问，这种排他性的对象我们称作资源。资源又分为可剥夺和不可剥夺的。可剥夺的资源不会产生死锁。

死锁有4个条件，任一一个打破即可解除死锁。

1. 互斥条件，一个资源每次只能被一个进程使用。
2. 请求与保持条件: 一个进程因请求资源而阻塞时，对已获得的资源保持不放。
3. 不剥夺条件: 进程已获得的资源，在未使用完之前，不能强行剥夺。
4. 循环等待条件: 若干进程之间形成一种头尾相接的循环等待资源关系。

处理死锁有四种策略：

1. 忽略该问题
2. 检测死锁并恢复
3. 仔细地对资源进行动态分配，以避免死锁。
4. 通过破除所述的四个条件中的任意一个条件，用以防止死锁产生。

死锁的检测:

• 单资源类型的检测，判断资源分配有向图是否存在环，存在即可能死锁。
• 多资源类型的检测， 使用资源矩阵分别记录资源总数，可用资源数以及进程申请资源数，然后检测是否有进程满足申请数少于可用数存在则该进程可正常获取资源，并最终释放已占用的资源(即是若找到进程满足，则可用资源数矩阵值应加上该进程的占用值。)如果遍历完了矩阵，没有找到符合条件的，则表示会发生死锁，结束算法。
  阅读全文 »

在写简易 shell 程序的时候，因 waitpid 函数的使用不当导致程序出现了预料之外的行为。求助了各路高手，找了一天，最后终于定位到了源头，原来是很细小的问题导致。

caddy 是一个 Go 语言实现的轻量级 web server. 因其配置简单所以用来本地联调前后端分离的项目特别方便.此处安利两个功能 前后端联调 和 全站自动升级 HTTPS
Caddy 官网

Mac OS && Linux 安装:

在官网选择需要的插件, 然后 copy installer script 执行。以 64bit Linux 为例:

今天应该是这个冬天以来最早到公司的一天，办完离职手续今天也就离职了。这个冬天太慵懒了，每天睡到9点才慢条斯理起床来公司。跟印象中早起晚睡加班熬夜的程序猿好像不太一样？大概得得益于遇到一个好的老大吧。昨晚跟老大一起吃饭，还在感慨一晃在公司就呆了将近半年。真的很快。要离职了，忽然感觉很迷茫。不知道应该回去准备考研，还是备战春招，秋招…
互联网行业的变化真是太快了，前几年移动端还异常火爆，大军涌入，这才过一两年就冷了下来。大有 JavaScript 一统 web, 移动端，PC 端的势头，因而前端又热得发烫。如果就此准备秋招，本科毕业进军相对稳定的后端开发，谁又说得准这块不会很快就被 AI 取代了呢？ 实在纠结。对行业的迷茫，对前路的迷茫。可又能怎么办呢？
离职后，先回家过个春节再看吧。路有很多，现在还能进行选择。真正应当焦虑的，或许是自己没有选择余地的时候吧~

基础设定: 仅以薪资作为计算对象, 默认硕士读三年, 不考虑读研期间的学杂费, 生活花销.
设
　　本科毕业即就业的底薪为 x , 提薪速度为 y, 收益 totalMoney.
　　硕士毕业就业底薪为 m , 提薪速度为 n, 收益 totalMoney.
　　t 为本科毕业的工作时间, 以年为单位.
公式(即等比数列求和):
　　本科生:
　　硕士:
化简得到代码中的公式.

在一篇介绍 HTTP 监控框架的推文中, 作者针对监控框架常见玩法的弊端进行了分析, 提出了相应结合业务特性的解决方案. 在实际的应用中效果如何, 鄙人这般弱鸡暂时还没有接触过, 因此暂时不讨论这个问题.
其文中提到「 HTTP 状态码监控的弊端」使我产生了一番兴趣. 为了不产生阅读障碍, 我将文章部分摘抄在下面.

CRITICAL SECTION, RACE CONDITION, INDETERMINATE, MUTUAL EXCLUSION
These four terms are so central to concurrent code that we thought it worth while to call them out explicitly.

In Unix/C programs, understanding how to allocate and manage memory is critical in building robust and reliable software. What mistakes should be avoided?

• The major goal of a virtual memory (VM) system is transparency.

  This usage of transparency is sometimes confusing; some students think that “being transparent” means keeping everything out in the open, i.e., what government should be like. Here, it means the opposite: that the illusion provided by the OS should not be visible to ap- plications. Thus, in common usage, a transparent system is one that is hard to notice, not one that responds to requests as stipulated by the Freedom of Information Act.