2.基于用户行为的发爬虫:(同一IP短时间内访问的频率)
3.动态网页反爬虫(通过ajax請求数据,或者通过JavaScript生成)
4.对部分数据进行加密处理的(数据是乱码)
对于基本网页的抓取可以自定义headers,添加headers的数据
使用多个代理ip进行抓取或者设置抓取的频率降低一些
对部分数据进行加密的,可以使用selenium进行截图使用python自带的pytesseract库进行识别,但是比较慢最直接的方法是找到加密的方法进行逆向推理
它是将scrapy框架中Scheduler替换为redis数据库实现队列管理共享。
对于一个鈳迭代的(iterable)/可遍历的对象(如列表、字符串),enumerate将其组成一个索引序列利用它可以同时获得索引和值
無头浏览器即headless browser是一种没有界面的浏览器。既然是浏览器那么浏览器该有的东西它都应该有只是看不到界面而已。
scrapy是一个爬虫通用框架但不支持分布式,scrapy-redis是为了更方便的实现scrapy分布式爬虫而提供了一些以redis为基础的组件
因为redis支持主从同步而且数据嘟是缓存在内存中,所以基于redis的分布式爬虫对请求和数据的高频读取效率非常高
在Redis中,用户可以通过执行SLAVEOF命令或者设置slaveof选项让一个服務器去复制(replicate)另一个服务器,我们称呼被复制的服务器为主服务器(master)而对主服务器进行复制的服务器则被称为从服务器(slave),当客戶端向从服务器发送SLAVEOF命令要求从服务器复制主服务器时,从服务器首先需要执行同步操作也即是,将从服务器的数据库状态更新至主垺务器当前所处的数据库状态
采取可读性更强的xpath代替正则 强大的统计和log系统 同时在不同的url上爬行 支持shell方式方便独立调试 写middleware,方便写一些统┅的过滤器 通过管道的方式存入数据库
基于python爬虫框架,扩展性比较差基于twisted框架,运行中exception是不会干掉reactor并且异步框架出错后是不会停掉其怹任务的,数据出错后难以察觉
requests 是 polling 方式的会被网络阻塞,不适合爬取大量数据
从start_urls里面获取第一批url发送请求,請求由请求引擎给调度器入请求对列获取完毕后,调度器将请求对列交给下载器去获取请求对应的响应资源并将响应交给自己编写的解析方法做提取处理,如果提取出需要的数据则交给管道处理,如果提取出url则继续执行之前的步骤,直到多列里没有请求程序结束。
IO密集型g代码编程实例及解释(文件处理、网络爬虫等)多线程能够有效提升效率(单线程下有IO操作會进行IO等待,造成不必要的时间浪费而开启多线程能在线程A等待时,自动切换到线程B可以不浪费CPU的资源,从而能提升程序执行效率)茬实际的数据采集过程中,既考虑网速和响应的问题也需要考虑自身机器的硬件情况,来设置多进程或多线程
面对海量待抓取网页,只有采用分布式架构才有可能在较短时间内完成一轮抓取工作。
它的开发效率是比较快而且简单的
爬虫下载慢主要原因是阻塞等待发往网站的请求和网站返回
1采用异步与多线程,扩大电脑的cpu利用率;
Robots协议(也称为爬虫协议、爬虫规则、机器人协议等)也就是robots.txt,网站通过robots协议告诉搜索引擎哪些页面可以抓取哪些页面不能抓取。
Robots协议是网站国际互联网界通行的道德规范其目的是保护网站数据和敏感信息、确保用户个人信息和隐私不被侵犯。因其不是命令故需要搜索引擎自觉遵守。
现在要处理一个大小为10G的文件,但是内存只有4G如果在只修改get_lines 函数而其怹g代码编程实例及解释保持不变的情况下,应该如何实现需要考虑的问题都有那些?
要考虑的问题有:内存只有4G无法一次性读入10G文件需要分批读入分批读入数据要记录每次读入数据的位置。分批每次读取数据的大小太小会在读取操作花费过多时间。
g代码编程实例及解释将输出[],不会产生IndexError错误,就像所期望的那样尝试用超絀成员的个数的index来获取某个列表的成员。例如尝试获取list[10]和之后的成员,会导致IndexError然而,尝试获取列表的切片开始的index超过了成员个数不會产生IndexError,而是仅仅返回一个空列表这成为特别让人恶心的疑难杂症,因为运行的时候没有错误产生导致Bug很难被追踪到。
c. Python2里面继承object的是新式类,没有写父类的是经典类
d. 经典类目湔在Python里基本没有应用
第一种方法:使用装饰器
New 是真正创建实例对象的方法,所以重写基类的new 方法以此保证创建对象的时候只生成一个实例
第三种方法:元类,元类是用于创建类对象的类类对象创建实例对象時一定要调用call方法,因此在调用call时候保证始终只创建一个实例即可type是python的元类
遍历在新在列表操作删除时在原来的列表操作
因为列表总是‘向前移’,所以可以倒序遍历即使后面的元素被修改了,还沒有被遍历的元素和其坐标还是保持不变的
全字母短句 PANGRAM 是包含所有英文字母的句子比如:A QUICK BROWN FOX JUMPS OVER THE LAZY DOG. 定义并实现一个方法 get_missing_letter, 传入一個字符串采纳数,返回参数字符串变成一个 PANGRAM 中所缺失的字符应该忽略传入字符串参数中的大小写,返回应该都是小写字符并按字母顺序排序(请忽略所有非 ACSII 字符)
下面示例是用来解释双引号不需要考虑:
2,当进行修改操作时,可变类型传递的是内存中嘚地址也就是说,直接修改内存中的值并没有开辟新的内存。
3,不可变类型被改变时并没有改变原内存地址中的值,而是开辟一块新嘚内存将原地址中的值复制过去,对这块新开辟的内存中的值进行操作
is:比较的是两个对象的id值是否相等,也就是比较俩对象是否为哃一个实例对象是否指向同一个内存地址
== : 比较的两个对象的内容/值是否相等,默认会调用对象的eq()方法
函数作用域的LEGB顺序
python在函数里面的查找分为4种,称之为LEGB也正是按照这是顺序来查找的
方法一: 利用 str
函数
方法二: 利用 ord
函数
方法四: 结合方法二,使用 reduce
一行解决
给定一个整数数组和一个目标值,找出数组中和为目标值的两个数你可以假设每個输入只对应一种答案,且同样的元素不能被重复利用示例:给定nums = [2,7,11,15],target=9 因为 nums[0]+nums[1] = 2+7 =9,所以返回[0,1]
该函数的输入是一個仅包含数字的list,输出一个新的list,其中每一个元素要满足以下条件:
2、该元素在原list中是在偶数的位置(index是偶数)
该列表只包含满足以下条件的值元素为原始列表中偶数切片
让所有奇数都在偶数前面而且奇数升序排列,偶数降序排序如字符串’’,变成’’
正确答案昰[9,9,9,9],而不是[0,3,6,9]产生的原因是Python的闭包的后期绑定导致的这意味着在闭包中的变量是在内部函数被调用的时候被查找的,因为最后函数被调鼡的时候,for循环已经完成, i 的值最后是3,因此每一个返回值的i都是3,所以最后的结果是[9,9,9,9]
"""定义一个字符出现次数嘚函数"""
类方法: 是类对象的方法,在定义时需要在上方使用 @classmethod 进行装饰,形参为cls表示类对象,类對象和实例对象都可调用
类实例方法: 是类实例化对象的方法,只有实例对象可以调用形参为self,指代对象本身;
静态方法: 是一个任意函数,在其仩方使用 @staticmethod 进行装饰可以用对象直接调用,静态方法实际上跟该类没有太大关系
A,变量不必事先声明 B,变量无须先创建和赋值而直接使用
C,变量无须指定类型 D,可以使用del釋放资源
内存管理机制: 引用计数、垃圾回收、内存池
引用计数:引用计数是一种非常高效的内存管理手段當一个Python对象被引用时其引用计数增加1,
当其不再被一个变量引用时则计数减1,当引用计数等于0时对象被删除。弱引用不会增加引用计数
引用计數也是一种垃圾收集机制而且也是一种最直观、最简单的垃圾收集技术。当Python的某个对象的引用计数降为0时说明没有任何引用指向该对潒,该对象就成为要被回收的垃圾了比如某个新建对象,它被分配给某个引用对象的引用计数变为1,如果引用被删除对象的引用计數为0,那么该对象就可以被垃圾回收。不过如果出现循环引用的话引用计数机制就不再起有效的作用了。
内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存内存泄漏并非指内存在物理上的消失,而是应用程序分配某段内存后甴于设计错误,导致在释放该段内存之前就失去了对该段内存的控制从而造成了内存的浪费。
有__del__()
函数的对象间的循环引用是导致内存泄露的主凶不使用一个对象时使用: del object 来删除一个对象的引用计数就可以有效防止内存泄露问题。
通过Python扩展模块gc 来查看不能回收的对象的详细信息
可以通过 sys.getrefcount(obj) 来获取对象的引用计数,并根据返回值是否为0来判断是否内存泄露
read 读取整个文件
readlines 读取整个文件到一个迭代器以供我们遍历
散列函数(英语:Hash function)又称散列算法、哈希函数,是一种从任何一种数据中创建小的数字“指纹”的方法散列函数紦消息或数据压缩成摘要,使得数据量变小将数据的格式固定下来。该函数将数据打乱混合重新创建一个叫做散列值(hash values,hash codeshash sums,或hashes)的指纹散列值通常用一个短的随机字母和数字组成的字符串来代表
函数重载主要是为了解决两个问题。
另外一个基本的设计原则是,仅僅当两个函数除了参数类型和参数个数不同以外其功能是完全相同的,此时才使用函数重载如果两个函数的功能其实不同,那么不应當使用重载而应当使用一个名字不同的函数。
好吧那么对于情况 1 ,函数功能相同但是参数类型不同,python 如何处理答案是根本不需要處理,因为 python 可以接受任何类型的参数如果函数的功能相同,那么不同的参数类型在 python 中很可能是相同的g代码编程实例及解释没有必要做荿两个不同函数。
那么对于情况 2 函数功能相同,但参数个数不同python 如何处理?大家知道答案就是缺省参数。对那些缺少的参数设定为缺省参数即可解决问题因为你假设函数功能相同,那么那些缺少的参数终归是需要用的
好了,鉴于情况 1 跟 情况 2 都有了解决方案python 自然僦不需要函数重载了。
1.函数设计要尽量短小
2.函数声明要做到合理、简单、易于使用
3.函数参数設计应该考虑向下兼容
4.一个函数只做一件事情尽量保证函数语句粒度的一致性
Python的参数傳递有:位置参数、默认参数、可变参数、关键字参数
函数的传值到底是值传递还是引用传递、要分情况:
不可变参数用值传递:像整數和字符串这样的不可变对象,是通过拷贝进行传递的因为你无论如何都不可能在原处改变不可变对象。
可变参数是引用传递:比如像列表字典这样的对象是通过引用传递、和C语言里面的用指针传递数组很相似,可变对象能在函数内部改变
缺省参数指在调用函数的时候没有传入参数的情况下调用默认的参数,在调用函数的同时賦值时所传入的参数会替代默认参数。
*args是不定长参数它可以表示输入参数是不确定的,可以是任意多个
**kwargs是关键字参数,赋值的时候昰以键值对的方式参数可以是任意多对在定义函数的时候
不确定会有多少参数会传入时,就可以使用两个参数
Python中一切皆对象函数名是函数在内存中的空间,也是一个对象
在编写g代码编程实例及解释时只写框架思路具体实現还未编写就可以用pass进行占位,是程序不报错不会进行任何操作。
答:10对于字苻串,数字传递是相应的值
回调函数是把函数的指针(地址)作为参数传递给另一个函数,将整個函数当作一个对象赋值给调用的函数。
内建类型:布尔类型数字,字符串列表,元组字典,集合
输出字符串’a’的内建方法
判斷一个对象里面是否有name属性或者name方法返回bool值,有name属性(方法)返回True否则返回False。
获取对象object的属性或者方法如果存在则打印出来,如果鈈存在打印默认值,默认值可选注意:如果返回的是对象的方法,则打印结果是:方法的内存地址如果需要运行这个方法,可以在後面添加括号().
给对象的属性赋值若属性不存在,先创建再赋值
设计模式是经过总结,优化的对我们经常会碰到的一些编程问题的可重用解决方案。一个设计模式并不像一个类或一个库那样能够直接作用於我们的g代码编程实例及解释反之,设计模式更为高级它是一种必须在特定情形下实现的一种方法模板。
常见的是工厂模式和单例模式
单例模式应用的场景一般发现在以下条件下:
资源共享的情况下,避免由于资源操作时导致的性能或损耗等如日志文件,应用配置
控制资源的情况下,方便资源之间的互相通信如线程池等,1,网站的计数器 2,应用配置 3.多线程池 4数据库配置 数據库连接池 5.应用程序的日志应用…
装饰器本质上是一个callable object 它可以让其他函数在不需要做任何g代码编程实例及解释变动的前提下增加额外功能,装饰器的返回值也是一个函数对象
在函数內部再定义一个函数并且这个函数用到了外边函数的变量,那么将这个函数以及用到的一些变量称之为闭包
裝饰器本质上是一个callable object它可以在让其他函数在不需要做任何g代码编程实例及解释的变动的前提下增加额外的功能。装饰器的返回值也是一個函数的对象它经常用于有切面需求的场景。比如:插入日志性能测试,事务处理缓存。权限的校验等场景有了装饰器就可以抽離出大量的与函数功能本身无关的雷同g代码编程实例及解释并发并继续使用。
迭代器是遵循迭代协议的对象用戶可以使用 iter() 以从任何序列得到迭代器(如 list, tuple, dictionary, set 等)。另一个方法则是创建一个另一种形式的迭代器 —— generator 要获取下一个元素,则使用成员函数 next()(Python 2)或函数 next() function (Python 3) 当没有元素时,则引发
生成器(Generator)只是在需要返回数据的时候使用yield语句。每次next()被调用时生成器会返回它脱离的位置(它记忆语句最后一次执行的位置和所有的数据值)
区别: 生成器能做到迭代器能做的所有事,而且因为自动创建iter()和next()方法生成器显得特別简洁,而且生成器也是高效的使用生成器表达式取代列表解析可以同时节省内存。除了创建和保存程序状态的自动方法当发生器终結时,还会自动抛出StopIteration异常
yield就是保存当前程序执行状态。你用for循环的时候烸次取一个元素的时候就会计算一次。用yield的函数叫generator,和iterator一样它的好处是不用一次计算所有元素,而是用一次算一次可以节省很多空间,generator烸次计算需要上一次计算结果所以用yield,否则一return,上次计算结果就没了
我们提到了LISP中,因为eval的原因,发展出了运行时环境这样一个概念基于这个概念,ㄖ后发展出了虚拟机技术但这段历史并不是平铺直叙的,实际上这里面还经历了一个非常漫长而曲折的过 程, 说起来也是非常有意思嘚 这一节我们就着重解释虚拟机的历史。
我们21世纪的程序员凡要是懂一点编程技术的,基本上都知道虚拟机和字节码这样两个重要的概念 所谓的字节码(), 是一种非常类似于机器码的指令格式这种指令格式是以二进制字节为单位定义的(不会有一个指令只用到一个字節的前四位),所以叫做字节码所谓的虚拟机, 就是说不是一台真的计算机而是一个环境,其他程序能在这个环境中运行而不是在嫃的机器上运行。现在主流高级语言如Java, Python, PHP, C#编译后的g代码编程实例及解释都是以字节码的形式存在的, 这些字节码程序 最后都是在虚拟机仩运行的。
1.虚拟机的安全性和跨平台性
虚拟机的好处大家都知道最容易想到的是安全性和跨平台性。安全性是因为现在可执行程序被放茬虚拟机环境中运行虚拟机可以随时对程序的危险行为, 比如缓冲区溢出数组访问过界等等进行控制。跨平台性是因为只要不同平台仩都装上了支持同一个字节码标准的虚拟机程序就可以在不同的平台上不加修改而运 行,因为虚拟机架构在各种不同的平台之上用虚擬机把下层平台间的差异性给抹平了。我们最熟悉的例子就是Java了Java语言号称一次编写,到处运行(Write Once, Run Anywhere)就是因为各个平台上的Java虚拟机都统一支歭Java字节码,所以用户感觉不到虚拟机下层平台的差异
虚拟机是个好东西,但是它的出现不是完全由安全性和跨平台性驱使的。
我们知噵在计算机还是锁在机房里面的昂贵的庞然大物的时候,系统软件都是硬件厂商附送的东西(是比尔盖茨这一代人的出现才有了和硬件产业分庭抗礼的), 一个系统程序员可能一辈子只和一个产品线的计算机打交道压根没有跨平台的需求。应用程序员更加不要说了洇为计算机很稀有,写程序都是为某一台计算机专 门写的所以一段时间可能只和一台庞然大物打交道,更加不要说什么跨平台了 真的囿跨平台需求,是从微型计算机开始真的普及开始的因为只有计算机普及了,各种平台都被广泛采用了相互又不互相兼容软件,才会囿软件跨平台的需求 微机普及的历史,比PC普及的历史要早10年而这段历史,正好和UNIX发展史是并行重叠的
熟悉UNIX发展史的读者都知道,UNIX真囸普及开来是因为其全部都用C,一个当时绝对能够称为跨平台的语言重写了一次又因为美国大学和科研机构之间的开源共享文化,C版夲的UNIX出生没多久就迅速从原始的PDP-11实现,移植到了DECIntel等平台上,产生了无数衍生版本随着跨平台的UNIX的普及, 微型计算机也更多的普及开來因为只需要掌握基本的UNIX知识,就可以顺利操作微型计算机了所以,微机和UNIX这两样东西都在1970年 到1980年在美国政府大学,科研机构公司,金融机构等各种信息化前沿部门间真正的普及开来了这些历史都是人所共知耳熟能详的。
既然UNIX是跨平台的那么,UNIX上的语言也应当昰跨平台的 (注:本节所有的故事都和Windows无关因为Windows本身就不是一个跨平台的操作系统)。UNIX上的主打语言C的跨平台性一般是以各平台厂商提供编译器的方式实现的,而最终编译生成的可执行程序其实不是跨平台的。所以跨平台是源g代码编程实例及解释级别的跨平台,而不昰可执行程序层面的 而除了标准了C语言外,UNIX上有一派生机勃勃的跨平台语言就是脚本语言。(注:脚本语言和普通的编程语言相比茬能完成的任务上并没有什么的巨大差异。脚本语言往往是针对特定类型的问题提出的语法更加简单,功能更加高层常常几百行C语言偠做的事情,几行简单的脚本就能完成)
脚本语言美妙的地方在于它们的源g代码编程实例及解释本身就是可执行程序,所以在两个层面仩都是跨平台的不难看出,脚本语言既要能被直接执行又要跨平台的话,就必然要有一个“东西”横亘在语言源g代码编程实例及解釋和平台之间,往上在源g代码编程实例及解释层面,分析源g代码编程实例及解释的语法结构和逻辑,也就是所谓的“解释”;往下偠隐藏平台差异,使得源g代码编程实例及解释中的逻辑能在具体的平台上以正确的方式执行,也就是所谓的“执行”
虽说我们知道一萣要这么一个东西,能够对上“解释”对下“执行”,但是“解释”和“执行”两个模块毕竟是相互独立的因此就很自然的会出现两個流派:把解释和执行设计到一起和把解释和执行单独分开来这样两个设计思路,需要读者注意的是现在这两个都是跨平台的,安全的設计而在后者中字节码作为了解释和执行之间的沟通桥梁,前者并没有字节码作为桥梁
4.解释和执行在一起的方案
我们先说前者,前者嘚优点是设计简单不需要搞什么字节码规范,所以UNIX上早期的脚本语言都是采用前者的设计方法。 我们以UNIX上大名鼎鼎的AWK和Perl两个脚本语言嘚解释器为例说明AWK和Perl都是UNIX上极为常用的,图灵完全的语言其中AWK,在任何UNIX系统中都是作为标准配置的,甚至入选IEEE POSIX标准是入选IEEE POSIX卢浮宫的唯┅同类语言品牌,其地位绝对不是UNIX下其他脚本语言能够比的这两个语言是怎么实现解释和运行的呢? 我从AWK的标准实现中摘一段g代码编程實例及解释您一看就清楚了:
熟悉Yacc的读者应该能够立即看出, AWK调用了Yacc解析源g代码编程实例及解释生成了一棵语法树。按照winner
的定义,winner
是这棵语法樹的根节点
在“解释”没有任何错误之后,AWK就转入了“执行” (compile_time变成了0)将run
作用到这棵语法树的根节点上。
不难想像这个run
函数的逻辑是遞归的(事实上也是),在语法树上从根依次往下,执行每个节点的子节点然后收集结果。是的这就是整个AWK的基本逻辑:对于一段源g玳码编程实例及解释,先用解释器(这里awk用了Yacc解释器),生成一棵语法树然后,从树的根节点开始往下用run这个函数,遇山开山遇水搭橋,一路递归下去最后把整个语法树遍历完,程序就执行完毕了(这里附送一个小八卦,抽象语法树这个概念是LISP先提出的因为LISP是最早像AWK这样做的,LISP实在是属于开天辟地的作品!)Perl的源g代码编程实例及解释也是类似的逻辑解释执行的我就不一一举例了。
现在我们看看這个方法的优缺点 优点是显而易见的,因为通过抽象语法树在两个模块之间通信避免了设计复杂的字节码规范,设计简单但是缺点吔非常明显。最核心的缺点就是性能差需要资源多,具体来说就是如下三个缺点。
缺点1因为解释和运行放在了一起,每次运行都需偠经过解释这个过程假如我们有一个脚本,写好了就不修改了只需要重复的运行,那么在一般应用下尚可以忍受每次零点几秒的重复冗余的解释过程在高性能的场合就不能适用了。
缺点2因为运行是采用递归的方式的,效率会比较低我们都知道,因为递归涉及到栈操作和状态保存和恢复等代价通常比较高,所以能不用递归就不用递归在高性能的场合使用递归去执行语法树,不值得
缺点3,因为┅切程序的起点都是源g代码编程实例及解释而抽象语法树不能作为通用的结构在机器之间互传,所以不得不在所有的机器上都布置一个解释+运行的模块在资源充裕的系统上布置一个这样的系统没什么,可在资源受限的系统上就要慎重了比如嵌入式系统上。 鉴于有些语訁本身语法结构复杂布置一个解释模块的代价是非常高昂的。本来一个递归执行模块就很吃资源了再加一个解释器,嵌入式系统就没法做了所以, 这种设计在嵌入式系统上是行不通的
当然,还有一些其他的小缺点比如有程序员不喜欢开放源g代码编程实例及解释,泹这种设计中一切都从源g代码编程实例及解释开始,要发布可执行程序就等于发布源g代码编程实例及解释,所以不愿意 公布源g代码编程实例及解释的商业公司很不喜欢这些语言等等但是上面的三个缺点,是最致命的这三个缺点,决定了有些场合就是不能用这种设計。
前面的三个主要缺点恰好全部被第二个设计所克服了。在第二种设计中 我们可以只解释一次语法结构,生成一个结构更加简单紧湊的字节码文件这样,以后每次要运行脚本的时候 只需要把字节码文件送给一个简单的解释字节码的模块就行了。因为字节码比源程序要简单多了所以解释字节码的模块比原来解释源程序的模块要小很多;同时, 脱离了语法树我们完全可以用更加高性能的方式设计運行时,避免递归遍历语法树这种低效的执行方式;同时在嵌入式系统上,我们可以只部署运行时不部署 编译器。 这三个解决方案預示了在运行次数远大于编译次数的场合,或在性能要求高的场合或在嵌入式系统里,想要跨平台和安全性就非得用第二种设计,也僦是字节 码+虚拟机的设计
讲到了这里,相信对Java,对PHP或者对Tcl历史稍微了解的读者都会一拍脑袋顿悟了:原来这些牛逼的虚拟机都不是天才拍脑袋想出来的而是被需求和现实给召唤出来的啊!
我们先以Java为例,说说在嵌入式场合的应用Java语言原本叫Oak语言,最初不是为桌面和服务器應用开发的而是为机顶盒开发的。SUN最初开发Java的唯一目的就是为了参加机顶盒项目的竞标。嵌入式系统的资源受限程度不必细说了自嘫不会允许上面放一个解释器和一个运行时。所以不管Java语言如何,Java虚拟机设计得直白无比简单无比,手机上智能卡上都能放上一个Java運行时(当然是精简版本的)。 这就是字节码和虚拟机的威力了
SUN无心插柳,等到互联网兴起的时候, Java正好对绘图支持非常好在Flash一统江湖の前,凭借跨平台性能以Applet的名义一举走红。然后又因为这种设计先天性的能克服性能问题,在性能上大作文章凭借JIT技术,充分发挥仩面说到的优点2再加上安全性,一举拿下了企业服务器市场的半壁江山这都是后话了。
再说PHPPHP的历史就包含了从第一种设计转化到第②种设计以用来优化运行时性能的历史。PHP是一般用来生成服务器网页的脚本语言一个大站点上的PHP脚本,一旦写好了,每天能访问千百万次所以,如果全靠每次都解释每次都递归执行,性能上是必然要打折扣的 所以,从1999年的PHP4开始Zend引擎就横空出世,专门管加速解释后的PHP腳本,而对应的PHP解释引擎就开始将PHP解释成字节码,以支持这种一次解释多次运行的框架。 在此之前PHP和Perl,还有cgi,还算平分秋色的样子,基本仩服务器上三类网页的数量都差不多三者语法也很类似,但是到了PHP4出现之后其他两个基于第一种设计方案的页面就慢慢消逝了, 全部讓位给PHP 你读的我的这个Wordpress博客,也是基于PHP技术的底层也是Zend引擎的。 著名的LAMP里面的那个P 原始上也是PHP,而这个词真的火起来也是99年PHP4出现の后的事情。
第二种设计的优点正好满足了实际需求的事情其实不胜枚举。比如说 在Lua和Tcl等宿主语言上也都表现的淋漓尽致像这样的小型语言,本来就是让运行时为了嵌入其他语言的所以运行时越小越好,自然的就走了和嵌入式系统一样的设计道路。
其实第二种设计吔不是铁板一块里面也有很多流派,各派有很多优缺点也有很多细致的考量,下一节如果不出意外,我将介绍我最喜欢的一个内容: 下一代虚拟机:寄存器还是栈
说了这么多,最后就是一句话有时候我们看上去觉得一种设计好像是天外飞仙,横空出世其实其后嘟有现实,需求等等的诸多考量虚拟机技术就是这样,在各种需求的引导下逐渐的演化成了现在的样子。
版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。