58同城 20xx研发一面面试来临了，你准备好了吗?面试时不要紧张，下面就由小编为大家介绍一下58同城20xx研发面试题的文章，欢迎阅读。

　　>58同城20xx研发面试题篇1

　　1.手写KMP算法

　　我猜测考这道题并不是真的要被面者把KMP算法一字不漏的写出来(当然能写出来最好)，面试官一上来就出一道很难的题可能有两点用意：

　　1)看看被面者心理承受能力，是说道KMP就跪地求饶呢还是拼死拼活写点算点?心态很重要，显然后者更好

　　2)写出代码了，看看被面者的代码风格怎么样?有没有把代码写得很鲁棒?有没有考虑到边界?有没有用简洁易懂的变量名?

　　2.0.线程和进程的区别

　　1)进程是CPU分配资源的最小单位，线程是CPU调度的最小单位

　　2)进程之间是独立的，每个进程独享资源(如内存空间)，而线程间是共享内存(除了栈以及寄存器外)。因此在线程间可以直接互相通行(直接访问同一块内存)，而进程之间需要特殊手段，例如管道、消息队列、共享内存、信号，socket等

　　3)线程是轻量级的进程，开销通常要比进程小，因此能用线程的地方尽量用线程。

　　4)一个进程至少拥有一个线程，即主线程(Main Thread)

　　2.1既然线程比进程开销要小，那具体小在哪里?

　　线程的开销是明显小于进程开销的,主要体现在创建和上下文切换的时候。我在一本书上看到，Solaris 2中 进程的创建要比线程创建慢30倍 ，进程切换要比线程切换慢5倍。那么，为什么进程和线程的效率差别如此之大呢?

　　1)资源开销：操作系统每创建一个进程，就要为之分配一笔很大的资源，比如I/O，内存等，而每个线程所占用的资源要比进程小得多。通常线程自己只需要独立的栈空间和寄存器空间就可以了，其他资源都和其他兄弟线程共享。因此在创建的时候，进程要比线程慢得多

　　2)操作系统的管理：每个进程有一个PCB，每一个线程有个TCB，分别记录的都是进程和线程的当前状态。但是，PCB要比TCB大得多，是一个庞大的结构体(struct)，在进程切换时，涉及到整个当前进程环境的保存环境的设置以及新被调度运行的环境的设置(即先将当前进程的状态保存到自己的PCB中，再用新进程的PCB初始化当前运行环境)，而线程切换只需保存和设置少量的寄存器的内容(也是保存在TCB中)

　　2.2哪些情况下必须要用进程?

　　我们说过，在能用线程的地方尽量用线程，因为线程无论在资源占有还是效率上都优于进程。但是，进程的存在，也是有其必要的。下面就谈谈什么时候用线程更恰当，什么时候用进程更恰当。其理论依据，还是在线程和进程本身的特点和区别。

　　1)需要频繁创建销毁的优先用线程

　　原因请看上面的对比。

　　这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的

　　2)需要进行大量计算的优先使用线程

　　所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。

　　这种原则最常见的是图像处理、算法处理。

　　3)强相关的处理用线程，弱相关的处理用进程

　　什么叫强相关、弱相关?理论上很难定义，给个简单的例子就明白了。

　　一般的Server需要完成如下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业务处理”，这两个任务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。

　　当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。

　　个人理解：强相关涉及到两个工作任务之间的强依赖，如频繁交换信息;弱相关就是两个工作任务间几乎没有交流，各自独立工作。

　　4)可能要扩展到多机分布的用进程，多核分布的用线程

　　5)都满足需求的情况下，用你最熟悉、最拿手的方式

　　至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。

　　需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼的误区。

　　>58同城20xx研发面试题篇2

　　1.0.http怎么传输数据的?

　　1.1.http长连接和短连接的区别以及使用时机

　　2.C#怎么管理内存的?

　　>58同城20xx研发面试题篇3

　　如果你需要你的上司给你写一个模块，两天之后你要用到，但是上司要在第三天才给你，导致你的工期延误，你会怎么做?

　　补充：今天收到58给的offer，薪资还算给力。总结了一下成功的原因，发现还是有很多技巧的。实力肯定必须摆在首位。但是，面试的成功不仅仅靠实力说话，成功的标准是“通过这几十分钟的沟通，结束之后面试官是否乐意今后与你共事。如果他感觉很好，面试就成功了;如果他觉得以后不想和你相处，面试就失败了。”因此，博得面试官的好感大于把每一道题都准确无误地“背”出来。经过这么多长面试，我觉得面试时注意以下几点：

　　1)多和面试官交流想法而不是“他问你答”的刻板面试。

　　2)代码的风格(变量命名规则，缩进，函数命名，代码整洁度，鲁棒性等)大于代码的正确性，因为你的代码他能力再高也不会在很短的时间内读的很透彻，大部分精力应该就放在风格和边界值等上了。但是，也不能犯那种重大的逻辑错误(只要面试官凭感觉看不出来就可以了)。

　　3)说脏话在一定程度上会起到良好的效果。但是，要有个度!偶尔一句“TMD”“坑爹”“这道题最蛋疼了...”"代码写得乱七八糟的..."等有助于打破“很正规”的面试气氛。更平等地交流。(PS：你和你的同学、同事说话不会有任何拘束吧，把面试官就看成你的同学或同事)

　　4)当遇到不会的题或不明白的知识点，又需要表现的十分谦虚和好学。勇敢地把你不清楚的说出来和面试官交流讨论而不是忽略过去避而不谈。比如可以说“我在很多地方都见到多这道题但是一直没有找到一个满意的答案，您能给我讲讲思路么?”或者说“我感觉这道题可以用方法做，而且时间复杂度还不错，但是具体的思路还没有想透彻!”

　　5)当面是官甩给你一道题后你感觉可以用O(n)的时间复杂度完成但是仅仅找到了O(n^2)的解法，这是不妨这么说“我曾经记得有个O(n)时间复杂度的解法，但是现在只想到了一个O(n^2)的解法，不妨我说一下思路吧，您看看还有什么改进的地方没。”然后补充道“其实有时候过分关注算法的时间复杂度并不是好的软件工程思想，很多时候花了大部分精力优化的地方并不是性能的瓶颈，还不如一个复杂度稍差但清晰易懂的算法呢!”

　　6)加分点：你的技术博客、平时看的书、经常浏览的论坛、参加的项目、关注的最新技术(哪怕只能说出皮毛)、崇拜的偶像(当然是IT行业的，周润发什么的就别说了)、新奇的想法等。在面试的过程中尽可能抖出来，比如说“我在论坛上看见他们是这么讨论这个问题的.....”比“我觉得是这个问题应该这样解决....”要好。总之，尽量在交流中把这些点说出来