• 关于

    里所码可以做什么

    的搜索结果

回答

提交注册表单到后端处理时,调用第三方短信服务(手机号码,后端生成验证码),限制多少时间内重发。验证码可以保存数据库中有效时间,或者session中设置过期时间问题有些太开放,宽松制约。重新考虑一下需求;如你所说的确实是个问题。或者其他人解答一下手机号码注册,短信只作验证功能(省事,用户群体比较有质量,手机号码唯一性,防止恶意刷注册用户数)/邮箱验证也可以,用户体验上手机较好(后期还可以通过手机号码去分析用户) 如果每次登陆都用短信验证码(短信服务还是要钱的...这个一天登陆一多就懂) ######首先 非常感谢你这么认真的回答。 我看完后 再回复你。先谢谢你###### 1. 你们服务端生成 短信 内容 提交到他们那,验证码可以放到缓存里,用户确定的时候检查缓存.写一个公共的服务组件, Linux可用crontab Win可用定时任务,在指定时间段内 每分钟查询下数据库,提交到短信提供商.最好不要使用短信登陆. ######关于问题1 ,一般都是用户前台输入手机号,点击获取验证码按钮后先在自己服务器根据短信服务商的接口规范生成url(包括验证码的生成,生成之后保存在session或者数据库中),然后用curl发请求,收到一个唯一的短信id就表示发送成功了(但是有可能是对方服务器出了问题,收到了id用户还没收到短信,我遇到过这个问题,最后他们换了一个线路解决了)###### 引用来自“p2ng”的评论 提交注册表单到后端处理时,调用第三方短信服务(手机号码,后端生成验证码),限制多少时间内重发。验证码可以保存数据库中有效时间,或者session中设置过期时间问题有些太开放,宽松制约。重新考虑一下需求;如你所说的确实是个问题。或者其他人解答一下手机号码注册,短信只作验证功能(省事,用户群体比较有质量,手机号码唯一性,防止恶意刷注册用户数)/邮箱验证也可以,用户体验上手机较好(后期还可以通过手机号码去分析用户) 如果每次登陆都用短信验证码(短信服务还是要钱的...这个一天登陆一多就懂) 回复1: 一般大家的普通做法是 保持数据库中还是SESSION中 还是内存中啊。  验证码好像就是临时的吧。 这个手机验证码 是需要我自定义生成吗? 我做过登陆图形验证码。用户输入后判断下。就行。提交一次重新生成。 但这个貌似可以提交多次,直到你输入正确的短信验证码是吧? 回复2: 举个简单例子吧: 我加入要做个提醒的功能。  我在web网站上 设置好时间,设置后内容。然后我当天那个时间收到这个短信内容。 我就是提供给会员这个事情。  比如我做一个比赛预告的WEB页面,用户点击比赛前1小时短信提醒我。  回复3: 每次短信登陆的确很麻烦也很费钱。 但类似微博就是这种的啊。 可以提供手机短信登陆的啊。 短信登陆唯一好处就是 用户注册/登陆都一样的,这样用户注册的时候就没有密码设置这一项,用户第一次实用的体验度会很好。。。。 ###### 引用来自“金马超”的评论 你们服务端生成 短信 内容 提交到他们那,验证码可以放到缓存里,用户确定的时候检查缓存.写一个公共的服务组件, Linux可用crontab Win可用定时任务,在指定时间段内 每分钟查询下数据库,提交到短信提供商.最好不要使用短信登陆. 回复1: 大体思路我明白了,只是之前没做过短信注册这个模块。 我看看第三方1069通道的 应该不难。 或者网上搜搜下 回复2: linux的crontab定时任务和win我都会,但我的意思是 一个用户 写周四下午3点 那我这边就执行一个定时任务会不会太浪费了?也太多了? 或者你说,每分钟查下数据库 也就是每隔一分钟执行一个php脚本文件,遍历循环下? 有的话就发 没有的 就不发。 就等于轮询? 这样是不是很耗费服务器资源? 有没有其他解解方法 回复3: 你的意思是 短信注册可以,然后引导用户设置密码。 但手机短信登陆不建议ma? 但我的意思,像weibo就是手机短信验证码直接登陆 携程也是这样 还有一种是你说的只能手机+密码来登陆 那我的意思是,如果二者并行,怎么设计这个表。。。 ###### 引用来自“西南茂”的评论关于问题1 ,一般都是用户前台输入手机号,点击获取验证码按钮后先在自己服务器根据短信服务商的接口规范生成url(包括验证码的生成,生成之后保存在session或者数据库中),然后用curl发请求,收到一个唯一的短信id就表示发送成功了(但是有可能是对方服务器出了问题,收到了id用户还没收到短信,我遇到过这个问题,最后他们换了一个线路解决了) 回复1: 你的流程是   用户填手机号---》用户点击提交获取验证码--》服务器生成一个验证码---》这个验证码通过sdk 用curl发送到短信运营商---》短信运营商服务器收到后发到用户手机号上---》 用户收到输入这个验证码--》我们后台核对  OK? ######对,差不多就是这个流程###### 引用来自“金马超”的评论 你们服务端生成 短信 内容 提交到他们那,验证码可以放到缓存里,用户确定的时候检查缓存.写一个公共的服务组件, Linux可用crontab Win可用定时任务,在指定时间段内 每分钟查询下数据库,提交到短信提供商.最好不要使用短信登陆. 引用来自“kacc850”的评论 回复1: 大体思路我明白了,只是之前没做过短信注册这个模块。 我看看第三方1069通道的 应该不难。 或者网上搜搜下 回复2: linux的crontab定时任务和win我都会,但我的意思是 一个用户 写周四下午3点 那我这边就执行一个定时任务会不会太浪费了?也太多了? 或者你说,每分钟查下数据库 也就是每隔一分钟执行一个php脚本文件,遍历循环下? 有的话就发 没有的 就不发。 就等于轮询? 这样是不是很耗费服务器资源? 有没有其他解解方法 回复3: 你的意思是 短信注册可以,然后引导用户设置密码。 但手机短信登陆不建议ma? 但我的意思,像weibo就是手机短信验证码直接登陆 携程也是这样 还有一种是你说的只能手机+密码来登陆 那我的意思是,如果二者并行,怎么设计这个表。。。 写成一个公共的组件...   这个服务从指定的一张表里查询数据 eg  ID 内容 下发时间 手机号 ... 只要代码没问题的话  对服务器来说不会是什么太大的问题.嗯   是这样的,不建议短信登陆,可以用短信找回密码. 你们公司不是微博/携程,没人家那种财力,最好不要这么做, 而且短信这个行业也不是你想的那么简单,提交就能发的. 如果要并行的话,单独建立一张表用来记录短信登陆比较好. 用户表只放基本信息,短信登陆表 带上用户名,手机号,登陆时间,IP可有可无. 和用户表稍微关联下就行. ######硕达通短信平台,发验证码5秒到,发通知5秒到,速度快,到达率98%以上,成功计费(失败不计费)实时状态报告(成功失败一目了然)支持上下行 北京硕达通  www.shdat.com  买短信有红包!######凌凯短信:快/3秒响应 ·12年品牌塑造,三网(移动、联通、电信)通道,覆盖所有手机号码 ·3秒快速响应,行业领先(www.028lk.com)######雨林木风短信平台,三网合一,五秒达到,到达率99%,欢迎站内信哟~~~~

kun坤 2020-06-11 10:43:41 0 浏览量 回答数 0

回答

我们都知道虚拟机的内存划分了多个区域,并不是一张大饼。那么为什么要划分为多块区域呢,直接搞一块区域,所有用到内存的地方都往这块区域里扔不就行了,岂不痛快。是的,如果不进行区域划分,扔的时候确实痛快,可用的时候再去找怎么办呢,这就引入了第一个问题,分类管理,类似于衣柜,系统磁盘等等,为了方便查找,我们会进行分区分类。另外如果不进行分区,内存用尽了怎么办呢?这里就引入了内存划分的第二个原因,就是为了方便内存的回收。如果不分,回收内存需要全部内存扫描,那就慢死了,内存根据不同的使用功能分成不同的区域,那么内存回收也就可以根据每个区域的特定进行回收,比如像栈内存中的栈帧,随着方法的执行栈帧进栈,方法执行完毕就出栈了,而对于像堆内存的回收就需要使用经典的回收算法来进行回收了,所以看起来分类这么麻烦,其实是大有好处的。 提到虚拟机的内存结构,可能首先想起来的就是堆栈。对象分配到堆上,栈上用来分配对象的引用以及一些基本数据类型相关的值。但是·虚拟机的内存结构远比此要复杂的多。除了我们所认识的(还没有认识完全)的堆栈以外,还有程序计数器,本地方法栈和方法区。我们平时所说的栈内存,一般是指的栈内存中的局部变量表。 从图中可以看到有5大内存区域,按照是否被线程所共享可分为两部分,一部分是线程独占区域,包括Java栈,本地方法栈和程序计数器。还有一部分是被线程所共享的,包括方法区和堆。什么是线程共享和线程独占呢,非常好理解,我们知道每一个Java进行都会有多个线程同时运行,那么线程共享区的这片区域就是被所有线程一起使用的,不管有多少个线程,这片空间始终就这一个。而线程的独占区,是每个线程都有这么一份内存空间,每个线程的这片空间都是独有的,有多少个线程就有多少个这么个空间。上图的区域的大小并不代表实际内存区域的大小,实际运行过程中,内存区域的大小也是可以动态调整的。下面来具体说说每一个区域的主要功能。 程序计数器,我们在写代码的过程中,开发工具一般都会给我们标注行号方便查看和阅读代码。那么在程序在运行过程中也有一个类似的行号方便虚拟机的执行,就是程序计数器,在c语言中,我们知道会有一个goto语句,其实就是跳转到了指定的行,这个行号就是程序计数器。存储的就是程序下一条所执行的指令。这部分区域是线程所独享的区域,我们知道线程是一个顺序执行流,每个线程都有自己的执行顺序,如果所有线程共用一个程序计数器,那么程序执行肯定就会出乱子。为了保证每个线程的执行顺序,所以程序计数器是被单个线程所独显的。程序计数器这块内存区域是唯一一个在jvm规范中没有规定内存溢出的。 java虚拟机栈,java虚拟机栈是程序运行的动态区域,每个方法的执行都伴随着栈帧的入栈和出栈。 栈帧也叫过程活动记录,是编译器用来实现过程/函数调用的一种数据结构。栈帧中包括了局部变量表,操作数栈,方法返回地址以及额外的一些附加信息,在编译过程中,局部变量表的大小已经确定,操作数栈深度也已经确定,因此栈帧在运行的过程中需要分配多大的内存是固定的,不受运行时影响。对于没有逃逸的对象也会在栈上分配内存,对象的大小其实在运行时也是确定的,因此即使出现了栈上内存分配,也不会导致栈帧改变大小。 一个线程中,可能调用链会很长,很多方法都同时处于执行状态。对于执行引擎来讲,活动线程中,只有栈顶的栈帧是最有效的,称为当前栈帧,这个栈帧所关联的方法称为当前方法。执行引擎所运行的字节码指令仅对当前栈帧进行操作。Ft5rk58GfiJxcdcCzGeAt8fjkFPkMRdf 局部变量表:我们平时所说的栈内存一般就是指栈内存中的局部变量表。这里主要是存储变量所用。对于基本数据类型直接存储其值,对于引用数据类型则存储其地址。局部变量表的最小存储单位是Slot,每个Slot都能存放一个boolean、byte、char、short、int、float、reference或returnAddress类型的数据。 既然前面提到了数据类型,在此顺便说一下,一个Slot可以存放一个32位以内的数据类型,Java中占用32位以内的数据类型有boolean、byte、char、short、int、float、reference和returnAddress八种类型。前面六种不需要多解释,大家都认识,而后面的reference是对象的引用。虚拟机规范既没有说明它的长度,也没有明确指出这个引用应有怎样的结构,但是一般来说,虚拟机实现至少都应当能从此引用中直接或间接地查找到对象在Java堆中的起始地址索引和方法区中的对象类型数据。而returnAddress是为字节码指令jsr、jsr_w和ret服务的,它指向了一条字节码指令的地址。 对于64位的数据类型,虚拟机会以高位在前的方式为其分配两个连续的Slot空间。Java语言中明确规定的64位的数据类型只有long和double两种(reference类型则可能是32位也可能是64位)。值得一提的是,这里把long和double数据类型读写分割为两次32读写的做法类似。不过,由于局部变量表建立在线程的堆栈上,是线程私有的数据,无论读写两个连续的Slot是否是原子操作,都不会引起数据安全问题。 操作数栈是一个后入先出(Last In First Out, LIFO)栈。同局部变量表一样,操作数栈的最大深度也在编译的时候被写入到字节码文件中,关于字节码文件,后面我会具体的来描述。操作数栈的每一个元素可以是任意的Java数据类型,包括long和double。32位数据类型所占的栈容量为1,64位数据类型所占的栈容量为2。在方法执行的任何时候,操作数栈的深度都不会超过在max_stacks数据项中设定的最大值。 当一个方法刚刚开始执行的时候,这个方法的操作数栈是空的,在方法的执行过程中,会有各种字节码指令向操作数栈中写入和提取内容,也就是入栈出栈操作。例如,在做算术运算的时候是通过操作数栈来进行的,又或者在调用其他方法的时候是通过操作数栈来进行参数传递的。 举个例子,整数加法的字节码指令iadd在运行的时候要求操作数栈中最接近栈顶的两个元素已经存入了两个int型的数值,当执行这个指令时,会将这两个int值和并相加,然后将相加的结果入栈。 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配,在编译程序代码的时候,编译器要严格保证这一点,在类校验阶段的数据流分析中还要再次验证这一点。再以上面的iadd指令为例,这个指令用于整型数加法,它在执行时,最接近栈顶的两个元素的数据类型必须为int型,不能出现一个long和一个float使用iadd命令相加的情况。 本地方法栈 与虚拟机栈所发挥的作用是非常相似的,其区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则是为虚拟机使用到的Native方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定,因此具体的虚拟机可以自由实现它。甚至有的虚拟机(譬如Sun HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样,本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。 方法区经常会被人称之为永久代,但这俩并不是一个概念。首先永久代的概念仅仅在HotSpot虚拟机中存在,不幸的是,在jdk8中,Hotspot去掉了永久代这一说法,使用了Native Memory,也就是Metaspace空间。那么方法区是干嘛的呢?我们可以这么理解,我们要运行Java代码,首先需要编译,然后才能运行。在运行的过程中,我们知道首先需要加载字节码文件。也就是说要把字节码文件加载到内存中。好了,问题就来了,字节码文件放到内存中的什么地方呢,就是方法区中。当然除了编译后的字节码之外,方法区中还会存放常量,静态变量以及及时编译器编译后的代码等数据。 堆,一般来讲堆内存是Java虚拟机中最大的一块内存区域,同方法区一样,是被所有线程所共享的区域。此区域所存在的唯一目的就存放对象的实例(对象实例并不一定全部在堆中创建)。堆内存是垃圾收集器主要光顾的区域,一般来讲根据使用的垃圾收集器的不同,堆中还会划分为一些区域,比如新生代和老年代。新生代还可以再划分为Eden,Survivor等区域。另外为了性能和安全性的角度,在堆中还会为线程划分单独的区域,称之为线程分配缓冲区。更细致的划分是为了让垃圾收集器能够更高效的工作,提高垃圾收集的效率。 如果想要了解更多的关于虚拟机的内容,可以观看录制的<深入理解Java虚拟机>这套视频教程。

zwt9000 2019-12-02 00:21:07 0 浏览量 回答数 0

回答

是的,,,,,你还是先看看教程吧。 玩流媒体 我敢保证后面肯定会遇上很多问题的。######好的,谢谢,已经在看教程了,不过好多讲的都比较简单,感觉要想理解深入点还得看源码###### 一个文件里可以有不止1路视频、音频流。  请搞点ffmpeg的教程来看, 推荐看雷神的博客, 百度一下 leixiaohua  ######回复 @判官安子 : 在多种语言、多种字幕的片子里,你懂的。######你说的不止1路,是指有可能视频就有几路吗,那什么场景下会出现多路视频或音频呢###### 引用来自“明月惊鹊”的评论 一个文件里可以有不止1路视频、音频流。  请搞点ffmpeg的教程来看, 推荐看雷神的博客, 百度一下 leixiaohua  回复 @明月惊鹊 : 也就是说视频、字幕是分开成不同路的码流,这样的话,我们做同步不仅仅要做音频、视频的同步,还要做字幕的同步了, 再请教一问题:avcodec_decode_video2接口在解AVPaket包时,第三个参数表示是否成功解码一帧,意思是有可能需要几个AVPaket包才能解码出完整的一帧图像吗?我所了解多帧解码完整一帧的情况,只有场格式下。请问这里的多个AVPaket包解码一帧是场格式的情况吗?

kun坤 2020-06-07 14:26:09 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

哈希表 7月10日 【今日算法】

游客ih62co2qqq5ww 2020-07-11 07:14:35 6 浏览量 回答数 1

问题

如何从用户的角度来测试Web应用软件

技术小菜鸟 2019-12-01 21:41:25 3176 浏览量 回答数 1

问题

码农必备套件

仙游 2019-12-01 22:09:42 2528 浏览量 回答数 0

问题

对码农而言什么样的代码才能叫做好代码?

技术小菜鸟 2019-12-01 21:29:04 2417 浏览量 回答数 1

回答

错误代码简介 消费端通过 CSB 调用服务时,整个链路上可以分成三个阶段: 服务消费端应用以消费端协议访问 CSB。 CSB 处理转发服务调用请求。 CSB 以提供端协议访问服务提供端应用。 这三个阶段都可能出错,服务消费端收到错误信息时要能区别是在哪个阶段发生了什么错误,需要考虑如何通过消费端协议定义的错误信息结构来体现。消费端协议定义的错误信息结构多种多样,也可能有各种限制,但是通常都至少会提供错误码和错误描述,而且错误码应该都有保留或者未占用的、代表“其它错误”的编码(下称:逃逸代码 Escape Code)。基于这个前提,可以定义如下约定: 阶段1发生的错误不用做任何处理。 阶段2及之后发生的错误,约定使用消费端协议的某个 Escape Code,具体CSB错误码和描述以固定格式体现在消费端错误描述内,如[CSB Error Code] CSB Error Message。 阶段3发生的错误,同上处理,但是 CSB Error Code 也提供 Escape Code 表示这是一个阶段 3 错误,且 CSB Error Message 的格式定义为[提供端协议错误码] 提供端协议错误信息。 说明 CSB 需要了解提供端协议的错误码中哪些表示正常访问,以免将成功的访问当做错误处理。 CSB 错误码列表 其中 800 为 CSB Escape Code 。 错误代码 错误描述信息 说明 200 SUCCESS 请求处理成功 500 platform error 平台处理错误 501 access permission deny 没有权限访问 502 signature verification failed 验签失败 503 service not registed 服务没有注册 504 api name not found 该服务没有找到 505 access key not found Access Key 没有在参数里找到 506 signature not found 签名没有在参数里面找到 507 required parameter is missing 参数丢失 508 need to access security channel 需要能访问安全通道 509 timestamp not found 时间戳在参数里面没有找到 510 time expired 访问过期 511 invoke timeout 调用 HSF 服务超时 512 write channel error 转发 HSF 协议时,连接通道出错 513 connection has broken 连接已经断开 514 hsf address not found 调用时没有找到 HSF 服务地址 515 hsf process error 调用 HSF 出错 516 hoh process error 级联调用 HSF 出错 517 json2hsf process error HTTP 调用 HSF 失败 518 service metadata is null 发布的 HSF 服务信息为空 519 access permission deny by black list 访问被黑名单拒绝 520 can not found service metadata 调用是没有从缓存中找到 HSF 服务的元信息 521 access permission deny, ip is not in white list 访问者的 IP 没有加入白名单 522 this invoke protocol not open 该服务没有开放成此协议 523 access permission deny due to strict accesskey and ip white list 此凭证设置了白名单,需要访问者 IP 加入到白名单里 524 exceed access limition, try later 触发限流 800 service server error 服务调用出错 801 connect to service server error 连接不到服务提供者 802 serivce has offline from server 此服务已经下线 803 serivce has been stopped 服务已经在 CSB 上关闭了 99 hsf escap code HSF 逃逸错误代码 900 Unknown code 未知错误代码 1001 bad soap request SOAP 消息不正确 1002 bad response 返回结果不正确 1003 bad hsf subscribe info 错误的 HSF 订阅信息 1004 hsf invoke exception HSF 调用异常 1005 bad input soap parsing 输入 SOAP 消息解析失败 1006 bad output soap parsing 输出的 SOAP 消息解析失败 1007 bad invoke restful provider HTTP 服务 Provider 异常 1008 json2ws process error, bad input restufl/json request HTTP 调用 WS 失败,HTTP 请求不正确 1009 json2ws process error 调用 WS 服务失败 10001 process response result data filter failed 结果过滤处理结果失败 HSF 错误代码 错误代码 错误描述信息 说明 20 OK HSF 调用成功 30 client timeout 调用端超时 31 server timeout 服务端超时 40 bad request 请求不合法 50 bad response 返回结果不合法 60 service not found 服务没有找到 70 service error 服务错误 79 connection has broken 连接已经断开 80 server error 服务提供端错误 81 Thread pool is busy 线程池繁忙 82 Communication error 通信异常 84 request is limited 请求被限流 88 server will close soon 服务很快就要关闭 90 client error 消费端错误 91 Unknown error 未知错误 消费端协议 Escape Code 列表 消费端协议 Escape Code HTTP类 500 HSF 99 示例 消费端应用以HSF协议通过CSB访问一个后端HSF服务,三个阶段的错误示例如下: 第一阶段错误 CSB 的 HSF 协议处理器发现消费端发出的 HSF 请求格式不正确,以 HSF 错误 40 bad request 直接回复消费端。 第二阶段错误 CSB 在处理消费端发出的 HSF 请求时,发现所访问的 API 并不存在,以 HSF 错误 99 [504]所访问的服务API(taobao.unknown)在实例(instance0733)上不存在 回复消费端。其中 99 为消费端协议 HSF 的 Escape Code。 第三阶段错误 CSB 处理消费端发出的 HSF 请求,在访问后端服务提供者时,HSF 服务框架报错 60 service not found,CSB 以HSF 错误 99 [800][60] service not found 回复消费端。其中 99 为消费端协议的 Escape Code,800 为 CSB 的 Escape Code。 第三阶段错误 CSB 处理消费端发出的 HSF 请求,在访问后端服务提供者时,HSF 服务提供应用出错,因为 HSF 框架不支持返回具体应用逻辑错误信息,仅仅报错为 80 server error,CSB 以 HSF错误 99 [800][80] server error 回复消费端。这里具体的应用错误只能在应用服务提供端看到,如果后端是其它比较开放的协议框架(用 X 代替),具体的应用错误信息可能可以报给 CSB,这样 CSB 才能返回更具体的错误信息 99 [800][X-Code] X-Message。

保持可爱mmm 2020-03-28 17:48:50 0 浏览量 回答数 0

问题

支付宝小程序云训练营优秀学员提问来啦

问问小秘 2020-06-15 15:57:38 159 浏览量 回答数 1

问题

wdcp使用说明/教程/问题集/FAQ汇总 『官网搬过来滴』

kideny 2019-12-01 21:26:36 18397 浏览量 回答数 6

回答

广大码农同学们大多都有个共识,认为算法是个硬骨头,很难啃,悲剧的是啃完了还未必有用——除了面试的时候。实际工程中一般都是用现成的模块,一般只需了解算法的目的和时空复杂度即可。 不过话说回来,面试的时候面算法,包括面项目中几乎不大可能用到的算法,其实并不能说是毫无道理的。算法往往是对学习和理解能力的一块试金石,难的都能掌握,往往容易的事情不在话下。志于高者得于中。反之则不成立。另一方面,虽说教科书算法大多数都是那些即便用到也是直接拿模块用的,但不幸的是,我们这群搬砖头的有时候还非得做些发明家的事情:要么是得把算法当白盒加以改进以满足手头的特定需求;要么干脆就是要发明轮子。所以,虽说面试的算法本身未必用得到,但熟悉各种算法的人通常更可能熟悉算法的思想,从而更可能具备这里说的两种能力。 那么,为什么说算法很难呢。这个问题只有两种可能的原因: 算法本身就很难。也就是说,算法这个东西对于人类的大脑来说本身就是个困难的事儿。 讲得太烂。 下面会说明,算法之所以被绝大多数人认为很难,以上两个原因兼具。 我们说算法难的时候,有两种情况:一种是学算法难。第二种是设计算法难。对于前者,大多数人(至少我当年如此)学习算法几乎是在背算法,就跟背菜谱似的(“Cookbook”是深受广大码农喜爱的一类书),然而算法和菜谱的区别在于,算法包含的细节复杂度是菜谱的无数倍,算法的问题描述千变万化,逻辑过程百转千回,往往看得人愁肠百结,而相较之下任何菜谱涉及到的基本元素也就那么些(所以程序员肯定都具有成为好厨师的潜力:D)注意,即便你看了算法的证明,某种程度上还是“背”(为什么这么说,后面会详述)。我自己遇到新算法基本是会看证明的,但是发现没多久还是会忘掉,这是死记硬背的标准症状。如果你也啃过算法书,我相信很大可能性你会有同感:为什么当时明明懂了,但没多久就忘掉了呢。为什么当时明明非常理解其证明,但没过多久想要自己去证明时却发现怎么都没法补上证明中缺失的一环呢。 初中学习几何证明的时候,你会不会傻到去背一个定理的证明。不会。你只会背结论。为什么。一方面,因为证明过程包含大量的细节。另一方面,证明的过程环环相扣,往往只需要注意其中关键的一两步,便能够自行推导出来。算法逻辑描述就好比定理,算法的证明的过程就好比定理的证明过程。但不幸的是,与数学里面大量简洁的基本结论不同,算法这个“结论”可不是那么好背的,许多时候,算法本身的逻辑就几乎包含了与其证明过程等同的信息量,甚至算法逻辑本身就是证明过程(随便翻开一本经典的算法书,看几个经典的教科书算法,你会发现算法逻辑和算法证明的联系有多紧密)。于是我们又回到刚才那个问题:你会去背数学证明么。既然没人会傻到去背整个证明,又为什么要生硬地去背算法呢。 那么,不背就不背,去理解算法的证明如何。理解了算法的证明过程,便更有可能记住算法的逻辑细节,理解记忆嘛。然而,仍然不幸的是,绝大多数算法书在这方面做的实在糟糕,证明倒是给全了,逻辑也倒是挺严谨的,可是似乎没有作者能真正还原算法发明者本身如何得到算法以及算法证明的思维过程,按理说,证明的过程应该反映了这个思维过程,但是在下文关于霍夫曼编码的例子中你会看到,其实饱受赞誉的CLRS和《Algorithms》不仅没能还原这个过程,反而掩盖了这个过程。 必须说明的是,没有哪位作者是故意这样做的,但任何人在讲解一个自己已经理解了的东西的时候,往往会无意识地对自己的讲解进行“线性化”,例如证明题,如果你回忆一下高中做平面几何证明题的经历,就会意识到,其实证明的过程是一个充满了试错,联想,反推,特例,修改问题条件,穷举等等一干“非线性”思维的,混乱不堪的过程,而并不像写在课本上那样——引理1,引理2,定理1,定理2,一口气直到最终结论。这样的证明过程也许容易理解,但绝对不容易记忆。过几天你就会忘记其中一个或几个引理,其中的一步或几步关键的手法,然后当你想要回过头来自己试着去证明的时候,就会发现卡在某个关键的地方,为什么会这样。因为证明当中并没有告诉你为什么作者当时会想到证明算法需要那么一个引理或手法,所以,虽说看完证明之后,对算法这个结论而言你是知其所以然了,但对于算法的证明过程你却还没知其所以然。在我们大脑的记忆系统当中,新的知识必须要和既有的知识建立联系,才容易被回忆起来(《如何有效地学习与记忆》),联系越多,越容易回忆,而一个天外飞仙似地引理,和我们既有的知识没有半毛钱联系,没娘的孩子没人疼,自然容易被遗忘。(为什么还原思维过程如此困难呢。我曾经在知其所以然(一)里详述) 正因为绝大多数算法书上悲剧的算法证明过程,很多人发现证明本身也不好记,于是宁可选择直接记结论。当年我在数学系,考试会考证明过程,但似乎计算机系的考试考算法证明过程就是荒谬的。作为“工程”性质的程序设计,似乎更注重使用和结果。但是如果是你需要在项目中自己设计一个算法呢。这种时候最起码需要做的就是证明算法的正确性吧。我们面试的时候往往都会遇到一些算法设计问题,我总是会让应聘者去证明算法的正确性,因为即便是一个“看上去”正确的算法,真正需要证明起来往往发现并不是那么容易。 所以说,绝大多数算法书在作为培养算法设计者的角度来说是失败的,比数学教育更失败。大多数人学完了初中平面几何都会做证明题(数学书不会要求你记住几何所有的定理),但很多人看完了一本算法书还是一团浆糊,不会证明一些起码的算法,我们背了一坨又一坨结论,非但这些结论许多根本用不上,就连用上的那些也不会证明。为什么会出现这样的差异。因为数学教育的理想目的是为了让你成为能够发现新定理的科学家,而码农系的算法教育的目的却更现实,是为了让你成为能够使用算法做事情的工程师。然而,事情真的如此简单么。如果真是这样的话干脆连算法结论都不要背了,只要知道算法做的是什么事情,时空复杂度各是多少即可。 如果说以上提到的算法难度(讲解和记忆的难度)属于Accidental Complexity的话,算法的另一个难处便是Essential Complexity了:算法设计。还是拿数学证明来类比(如果你看过《Introduction to Algorithms:A Creative Approach》就知道算法和数学证明是多么类似。),与单单只需证明相比,设计算法的难处在于,定理和证明都需要你去探索,尤其是前者——你需要去自行发现关键的那(几)个定理,跟证明已知结论相比(已经确定知道结论是正确的了,你只需要用逻辑来连接结论和条件),这件事情的复杂度往往又难上一个数量级。 一个有趣的事实是,算法的探索过程往往蕴含算法的证明过程,理想的算法书应该通过还原算法的探索过程,从而让读者不仅能够自行推导出证明过程,同时还能够具备探索新算法的能力。之所以这么说,皆因为我是个懒人,懒人总梦想学点东西能够实现以下两个目的: 一劳永逸:程序员都知道“一次编写到处运行”的好处,多省事啊。学了就忘,忘了又得学,翻来覆去浪费生命。为什么不能看了一遍就再也不会忘掉呢。到底是教的不好,还是学得不好。 事半功倍:事实上,程序员不仅讲究一次编写到处运行,更讲究“一次编写到处使用”(也就是俗称的“复用”)。如果学一个算法所得到的经验可以到处使用,学一当十,推而广之,时间的利用效率便会大大提高。究竟怎样学习,才能够使得经验的外推(extrapolate)效率达到最大呢。 想要做到这两点就必须尽量从知识树的“根节点”入手,虽然这是一个美梦,例如数学界寻找“根节点”的美梦由来已久(《跟波利亚学解题》的“一点历史”小节),但哥德尔一个证明就让美梦成了泡影(《永恒的金色对角线》));但是,这并不阻止我们去寻找更高层的节点——更具普适性的解题原则和方法。所以,理想的算法书或者算法讲解应该是从最具一般性的思维法则开始,顺理成章地推导出算法,这个过程应该尽量还原一个”普通人“思考的过程,而不是让人看了之后觉得”这怎么可能想到呢。 以本文上篇提到的霍夫曼编码为例,第一遍看霍夫曼编码的时候是在本科,只看了算法描述,觉得挺直观的,过了两年,忘了,因为不知道为什么要把两个节点的频率加在一起看做单个节点——一件事情不知道“为什么”就会记不牢,知道了“为什么”的话便给这件事情提供了必然性。不知道“为什么”这件事情便可此可彼,我们的大脑对于可此可彼的事情经常会弄混,它更容易记住有理有据的事情(从信息论的角度来说,一件必然的事情概率为1,信息量为0,而一件可此可彼的事情信息量则是大于0的)。第二遍看是在工作之后,终于知道要看证明了,拿出著名的《Algorithms》来看,边看边点头,觉得讲得真好,一看就理解了为什么要那样来构造最优编码树。可是没多久,又给忘了。这次忘了倒不是忘了要把两个节点的频率加起来算一个,而是忘了为什么要这么做,因为当时没有弄清霍夫曼为什么能够想到为什么应该那样来构造最优编码树。结果只知其一不知其二。 必须说明的是,如果只关心算法的结论(即算法逻辑),那么理解算法的证明就够了,光背算法逻辑难记住,理解了证明会容易记忆得多。但如果也想不忘算法的证明,那么不仅要理解证明,还要理解证明背后的思维,也就是为什么背后的为什么。后者一般很难在书和资料上找到,唯有自己多加揣摩。为什么要费这个神。只要不会忘记结论不就结了吗。取决于你想做什么,如果你想真正弄清算法设计背后的思想,不去揣摩算法原作者是怎么想出来的是不行的。

小旋风柴进 2019-12-02 01:21:29 0 浏览量 回答数 0

问题

比赛_快速入门_4_19_update_仅供参考,思维不要受局限

小斯never 2019-12-01 21:43:08 30563 浏览量 回答数 24

问题

拓扑排序 7月5日 【今日算法】

游客ih62co2qqq5ww 2020-07-07 09:48:17 19 浏览量 回答数 1

回答

. 在编写一个类时,如果该类中的代码可能运行与多线程环境下,就要考虑同步问题了。 会同时被多个线程访问的资源,就是竞争资源,也称为竞争条件。对于多线程共享的资源我们必须进行同步,以避免一个线程的改动被另一个线程所覆盖。 synchronized 关键字有两种作用域: 1> 某个对象实例内,synchronized aMethod(){}关键字可以防止多个线程访问对象的synchronized方法(如果一个对象有多个synchronized方法,只要一个线程访问了其中的一个synchronized方法,其它线程不能同时访问这个对象中任何一个synchronized方法)。这时,不同的对象实例的synchronized方法是不相干扰的。也就是说,其它线程照样可以同时访问相同类的另一个对象实例中的synchronized方法. 2> 是某个类的范围,synchronized static aStaticMethod{}防止多个线程同时访问这个类中的synchronized static 方法。它可以对类的所有对象实例起作用。 synchronized关键字是不能继承的,也就是说,基类的方法synchronized f(){} 在继承类中并不自动是synchronized f(){},而是变成了f(){}。继承类需要你显式的指定它的某个方法为synchronized方法; Java语言的关键字,当它用来修饰一个方法或者一个代码块的时候,能够保证在同一时刻最多只有一个线程执行该段代码。      一、当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时,一个时间内只能有一个线程得到执行。另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块。      二、然而,当一个线程访问object的一个synchronized(this)同步代码块时,另一个线程仍然可以访问该object中的非synchronized(this)同步代码块。      三、尤其关键的是,当一个线程访问object的一个synchronized(this)同步代码块时,其他线程对object中所有其它synchronized(this)同步代码块的访问将被阻塞。      四、第三个例子同样适用其它同步代码块。也就是说,当一个线程访问object的一个synchronized(this)同步代码块时,它就获得了这个object的对象锁。结果,其它线程对该object对象所有同步代码部   分的访问都被暂时阻塞。      五、以上规则对其它对象锁同样适用. 2. synchronized 关键字,它包括两种用法:synchronized 方法和 synchronized 块。   synchronized 方法:通过在方法声明中加入 synchronized关键字来声明 synchronized 方法。如:   synchronized void accessVal(int newVal);   synchronized 方法控制对类成员变量的访问:每个类实例对应一把锁,每个 synchronized 方法都必须获得调用该方法的类实例的锁方能 执行,否则所属线程阻塞,方法一旦执行,就独占该锁,直到从该方法返回时才将锁释放,此后被阻塞的线程方能获得该锁,重新进入可执行 状态。这种机制确保了同一时刻对于每一个类实例,其所有声明为 synchronized 的成员函数中至多只有一个处于可执行状态(因为至多只有 一个能够获得该类实例对应的锁),从而有效避免了类成员变量的访问冲突(只要所有可能访问类成员变量的方法均被声明为 synchronized) 。  在 Java 中,不光是类实例,每一个类也对应一把锁,这样我们也可将类的静态成员函数声明为 synchronized ,以控制其对类的静态成 员变量的访问。  synchronized 方法的缺陷:若将一个大的方法声明为synchronized 将会大大影响效率,典型地,若将线程类的方法 run() 声明为 synchronized ,由于在线程的整个生命期内它一直在运行,因此将导致它对本类任何 synchronized 方法的调用都永远不会成功。当然我们可 以通过将访问类成员变量的代码放到专门的方法中,将其声明为 synchronized ,并在主方法中调用来解决这一问题,但是 Java 为我们提供 了更好的解决办法,那就是 synchronized 块。   synchronized 块:通过 synchronized关键字来声明synchronized 块。语法如下:  synchronized(syncObject) {   //允许访问控制的代码  }  synchronized 块是这样一个代码块,其中的代码必须获得对象 syncObject (如前所述,可以是类实例或类)的锁方能执行,具体机 制同前所述。由于可以针对任意代码块,且可任意指定上锁的对象,故灵活性较高。  对synchronized(this)的一些理解 一、当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时,一个时间内只能有一个线程得到执行。另一个线 程必须等待当前线程执行完这个代码块以后才能执行该代码块。  二、然而,当一个线程访问object的一个synchronized(this)同步代码块时,另一个线程仍然可以访问该object中的非synchronized (this)同步代码块。  三、尤其关键的是,当一个线程访问object的一个synchronized(this)同步代码块时,其他线程对object中所有其它synchronized(this) 同步代码块的访问将被阻塞。  四、第三个例子同样适用其它同步代码块。也就是说,当一个线程访问object的一个synchronized(this)同步代码块时,它就获得了这个 object的对象锁。结果,其它线程对该object对象所有同步代码部分的访问都被暂时阻塞。  五、以上规则对其它对象锁同样适用 3.打个比方:一个object就像一个大房子,大门永远打开。房子里有 很多房间(也就是方法)。 这些房间有上锁的(synchronized方法), 和不上锁之分(普通方法)。房门口放着一把钥匙(key),这把钥匙可以打开所有上锁的房间。 另外我把所有想调用该对象方法的线程比喻成想进入这房子某个 房间的人。所有的东西就这么多了,下面我们看看这些东西之间如何作用的。 在此我们先来明确一下我们的前提条件。该对象至少有一个synchronized方法,否则这个key还有啥意义。当然也就不会有我们的这个主题了。 一个人想进入某间上了锁的房间,他来到房子门口,看见钥匙在那儿(说明暂时还没有其他人要使用上锁的 房间)。于是他走上去拿到了钥匙 ,并且按照自己 的计划使用那些房间。注意一点,他每次使用完一次上锁的房间后会马上把钥匙还回去。即使他要连续使用两间上锁的房间, 中间他也要把钥匙还回去,再取回来。 因此,普通情况下钥匙的使用原则是:“随用随借,用完即还。” 这时其他人可以不受限制的使用那些不上锁的房间,一个人用一间可以,两个人用一间也可以,没限制。但是如果当某个人想要进入上锁的房 间,他就要跑到大门口去看看了。有钥匙当然拿了就走,没有的话,就只能等了。 要是很多人在等这把钥匙,等钥匙还回来以后,谁会优先得到钥匙?Not guaranteed。象前面例子里那个想连续使用两个上锁房间的家伙,他 中间还钥匙的时候如果还有其他人在等钥匙,那么没有任何保证这家伙能再次拿到。 (JAVA规范在很多地方都明确说明不保证,象 Thread.sleep()休息后多久会返回运行,相同优先权的线程那个首先被执行,当要访问对象的锁被 释放后处于等待池的多个线程哪个会优先得 到,等等。我想最终的决定权是在JVM,之所以不保证,就是因为JVM在做出上述决定的时候,绝不是简简单单根据 一个条件来做出判断,而是 根据很多条。而由于判断条件太多,如果说出来可能会影响JAVA的推广,也可能是因为知识产权保护的原因吧。SUN给了个不保证 就混过去了 。无可厚非。但我相信这些不确定,并非完全不确定。因为计算机这东西本身就是按指令运行的。即使看起来很随机的现象,其实都是有规律 可寻。学过 计算机的都知道,计算机里随机数的学名是伪随机数,是人运用一定的方法写出来的,看上去随机罢了。另外,或许是因为要想弄 的确定太费事,也没多大意义,所 以不确定就不确定了吧。) 再来看看同步代码块。和同步方法有小小的不同。 1.从尺寸上讲,同步代码块比同步方法小。你可以把同步代码块看成是没上锁房间里的一块用带锁的屏风隔开的空间。 2.同步代码块还可以人为的指定获得某个其它对象的key。就像是指定用哪一把钥匙才能开这个屏风的锁,你可以用本房的钥匙;你也可以指定 用另一个房子的钥匙才能开,这样的话,你要跑到另一栋房子那儿把那个钥匙拿来,并用那个房子的钥匙来打开这个房子的带锁的屏风。          记住你获得的那另一栋房子的钥匙,并不影响其他人进入那栋房子没有锁的房间。          为什么要使用同步代码块呢?我想应该是这样的:首先对程序来讲同步的部分很影响运行效率,而一个方法通常是先创建一些局部变 量,再对这些变量做一些 操作,如运算,显示等等;而同步所覆盖的代码越多,对效率的影响就越严重。因此我们通常尽量缩小其影响范围。 如何做?同步代码块。我们只把一个方法中该同 步的地方同步,比如运算。          另外,同步代码块可以指定钥匙这一特点有个额外的好处,是可以在一定时期内霸占某个对象的key。还记得前面说过普通情况下钥 匙的使用原则吗。现在不是普通情况了。你所取得的那把钥匙不是永远不还,而是在退出同步代码块时才还。           还用前面那个想连续用两个上锁房间的家伙打比方。怎样才能在用完一间以后,继续使用另一间呢。用同步代码块吧。先创建另外 一个线程,做一个同步代码 块,把那个代码块的锁指向这个房子的钥匙。然后启动那个线程。只要你能在进入那个代码块时抓到这房子的钥匙 ,你就可以一直保留到退出那个代码块。也就是说 你甚至可以对本房内所有上锁的房间遍历,甚至再sleep(10601000),而房门口却还有 1000个线程在等这把钥匙呢。很过瘾吧。           在此对sleep()方法和钥匙的关联性讲一下。一个线程在拿到key后,且没有完成同步的内容时,如果被强制sleep()了,那key还一 直在 它那儿。直到它再次运行,做完所有同步内容,才会归还key。记住,那家伙只是干活干累了,去休息一下,他并没干完他要干的事。为 了避免别人进入那个房间 把里面搞的一团糟,即使在睡觉的时候他也要把那唯一的钥匙戴在身上。           最后,也许有人会问,为什么要一把钥匙通开,而不是一个钥匙一个门呢?我想这纯粹是因为复杂性问题。一个钥匙一个门当然更 安全,但是会牵扯好多问题。钥匙 的产生,保管,获得,归还等等。其复杂性有可能随同步方法的增加呈几何级数增加,严重影响效率。这也 算是一个权衡的问题吧。为了增加一点点安全性,导致效 率大大降低,是多么不可取啊。 synchronized的一个简单例子 public class TextThread { public static void main(String[] args) {    TxtThread tt = new TxtThread();    new Thread(tt).start();    new Thread(tt).start();    new Thread(tt).start();    new Thread(tt).start(); } } class TxtThread implements Runnable { int num = 100; String str = new String(); public void run() {    synchronized (str) {     while (num > 0) {      try {       Thread.sleep(1);      } catch (Exception e) {       e.getMessage();      }      System.out.println(Thread.currentThread().getName()        + "this is " + num--);     }    } } } 上面的例子中为了制造一个时间差,也就是出错的机会,使用了Thread.sleep(10) Java对多线程的支持与同步机制深受大家的喜爱,似乎看起来使用了synchronized关键字就可以轻松地解决多线程共享数据同步问题。到底如 何?――还得对synchronized关键字的作用进行深入了解才可定论。 总的说来,synchronized关键字可以作为函数的修饰符,也可作为函数内的语句,也就是平时说的同步方法和同步语句块。如果再细的分类, synchronized可作用于instance变量、object reference(对象引用)、static函数和class literals(类名称字面常量)身上。 在进一步阐述之前,我们需要明确几点: A.无论synchronized关键字加在方法上还是对象上,它取得的锁都是对象,而不是把一段代码或函数当作锁――而且同步方法很可能还会被其 他线程的对象访问。 B.每个对象只有一个锁(lock)与之相关联。 C.实现同步是要很大的系统开销作为代价的,甚至可能造成死锁,所以尽量避免无谓的同步控制。 接着来讨论synchronized用到不同地方对代码产生的影响: 假设P1、P2是同一个类的不同对象,这个类中定义了以下几种情况的同步块或同步方法,P1、P2就都可以调用它们。 1. 把synchronized当作函数修饰符时,示例代码如下: Public synchronized void methodAAA() { //…. } 这也就是同步方法,那这时synchronized锁定的是哪个对象呢?它锁定的是调用这个同步方法对象。也就是说,当一个对象P1在不同的线程中 执行这个同步方法时,它们之间会形成互斥,达到同步的效果。但是这个对象所属的Class所产生的另一对象P2却可以任意调用这个被加了 synchronized关键字的方法。 上边的示例代码等同于如下代码: public void methodAAA() { synchronized (this)      // (1) {        //….. } } (1)处的this指的是什么呢?它指的就是调用这个方法的对象,如P1。可见同步方法实质是将synchronized作用于object reference。――那个 拿到了P1对象锁的线程,才可以调用P1的同步方法,而对P2而言,P1这个锁与它毫不相干,程序也可能在这种情形下摆脱同步机制的控制,造 成数据混乱:( 2.同步块,示例代码如下: public void method3(SomeObject so) {     synchronized(so)     {        //…..     } } 这时,锁就是so这个对象,谁拿到这个锁谁就可以运行它所控制的那段代码。当有一个明确的对象作为锁时,就可以这样写程序,但当没有明 确的对象作为锁,只是想让一段代码同步时,可以创建一个特殊的instance变量(它得是一个对象)来充当锁: class Foo implements Runnable {         private byte[] lock = new byte[0]; // 特殊的instance变量         Public void methodA()         {            synchronized(lock) { //… }         }         //….. } 注:零长度的byte数组对象创建起来将比任何对象都经济――查看编译后的字节码:生成零长度的byte[]对象只需3条操作码,而Object lock = new Object()则需要7行操作码。 3.将synchronized作用于static 函数,示例代码如下: Class Foo {     public synchronized static void methodAAA()   // 同步的static 函数     {         //….     }     public void methodBBB()     {        synchronized(Foo.class)   // class literal(类名称字面常量)     } }    代码中的methodBBB()方法是把class literal作为锁的情况,它和同步的static函数产生的效果是一样的,取得的锁很特别,是当前调用这 个方法的对象所属的类(Class,而不再是由这个Class产生的某个具体对象了)。 记得在《Effective Java》一书中看到过将 Foo.class和 P1.getClass()用于作同步锁还不一样,不能用P1.getClass()来达到锁这个Class的 目的。P1指的是由Foo类产生的对象。 可以推断:如果一个类中定义了一个synchronized的static函数A,也定义了一个synchronized 的instance函数B,那么这个类的同一对象Obj 在多线程中分别访问A和B两个方法时,不会构成同步,因为它们的锁都不一样。A方法的锁是Obj这个对象,而B的锁是Obj所属的那个Class。 小结如下: 搞清楚synchronized锁定的是哪个对象,就能帮助我们设计更安全的多线程程序。 还有一些技巧可以让我们对共享资源的同步访问更加安全: 1. 定义private 的instance变量+它的 get方法,而不要定义public/protected的instance变量。如果将变量定义为public,对象在外界可以 绕过同步方法的控制而直接取得它,并改动它。这也是JavaBean的标准实现方式之一。 2. 如果instance变量是一个对象,如数组或ArrayList什么的,那上述方法仍然不安全,因为当外界对象通过get方法拿到这个instance对象 的引用后,又将其指向另一个对象,那么这个private变量也就变了,岂不是很危险。 这个时候就需要将get方法也加上synchronized同步,并 且,只返回这个private对象的clone()――这样,调用端得到的就是对象副本的引用了 作者:hanwei_java 来源:CSDN 原文:https://blog.csdn.net/hanwei_java/article/details/79738614 版权声明:本文为博主原创文章,转载请附上博文链接!

auto_answer 2019-12-02 01:50:26 0 浏览量 回答数 0

回答

疫情下的2020,程序员找工作和往年有什么不同?该如何寻找方向? ###行业环境 曾经 以前端为例,早期(2009年之前)的程序员岗位中,甚至都没有单独的前端岗位。页 面UI的设计与开发大多数都有后端包揽。存在感很小,那时候的程序员,也没有如今的火 热,在那个年代,金融行业仍是主流;那个电脑,程序员并没有如现在这般被大众所熟知与多金。 十年来风云莫测,Java易主了,node.js诞生了,互联网行业又重新注入了新的活力。 互联网行业同时也带动了周边相关行业的发展,比如IT培训、在线教育、社交电商等等, 从2011年淘宝双十一开始,淘宝真正成为国民电商平台的霸主。淘宝这个最大的电商平台, 可以说是一个集众多IT技术于一身的一个产物了。也是开启互联网时代的领头人,现如今 的时代,是移动互联网的世界。IT作为一个未来一个大时代的走向,是会越来越成熟,越 来越奔放的。 就薪资而言,曾经一直占领行业薪资top的金融行业,如今也被互联网岗位所取代。看到这里你可能会说某某财务总监年薪百万,可是你可曾想过,一个普通公司也许就那么一位或几位年薪百万的财务总监,但是在阿里巴巴这样的企业里,年薪百万未必非要坐上财务总监的位置,不完全统计,年薪百万的阿里人(开发岗)不低于4位数,技术驱动核心竞争力。那个时代,HTML5出世,移动互联网也迎来红利期,微信、今日头条、抖音等超级APP相继诞生 现在 不知怎么了,2019年起互联网行业内出现了很大波动,大批中小微企业倒闭、员工事业,不景气的企业用着正规或不正规的手段裁员,校招紧缩,员工生病被辞退等新闻被揭露。也许是互联网行业走向成熟,伴随着的优胜略汰的现象,如今的互联网,再也不是随便随便拿着PPT去路演就能拿到投资的行业,个人觉得,互联网行业在2020年将从“平台为王”向“服务为王”进行转换,谁能在服务上获得用户的认可,谁就有可能会获得更快的发展速度,所以对于大型互联网平台来说,2020年所面临的挑战还是非常大的。如果说在增量时代,互联网行业拼的是速度,那么在存量时代,互联网行业将开始拼服务,而服务体验度的不断提升是互联网行业发展的一个必然结果。 程序员现状 过去 过去的程序员找工作只要技术够牛就不会愁工作,2013年网上还盛传企业去教育培训机构挖人的新闻,如今这种现象是不会存在的。这也许就是一个行业走向稳定和成熟所伴随的稳重而不盲目。 对于程序员而言,所要关注的不该仅仅是技术本身了,学历、英语、沟通与表达能力也都非常重要。而前端为例,曾经写写jQ就能找到一份工作,在无内推的情况下,如今不会三大框架可能连简历都筛选不过去,行内盛传一句戏谑的话”面试造火箭,工作拧螺丝”,如今确实如此。个人决定,尽管行业不如从前,招聘要求也越来越高,作为一个有志气有报复的程序员,就应该紧跟行业的脚步,保持对行业的敏感,时时刻刻不能放弃学习,欲戴王冠必承其重。无论大家处于哪些行业哪种岗位,无论你是做算法岗还是业务应用开发,你都是在为互联网行业提供自己的一份力。GITHUB、StackOverFlow、掘金上那么多活跃的前辈、队友都在为互联网积极贡献开源项目,为这个行业发光发热。 未来 因为笔者是前端岗,我就以前端岗为例谈谈对当下及未来前端岗位的发展方向和技术要求。 当下前端热门的话题有AI、跨端应用、音视频等等。前端做AI在以前看来是否是不可能的事,我想大多数人和我一样,第一次听见“人工智能”这个词的时候都会觉得是一个很高大上、遥不可及的概念,我们对它的印象总是停留在各种各样神奇而又复杂的算法,这些仿佛都是那些名校博士才有能力去做的工作。我也曾一度以为自己和这个行业没有太多缘分,但自从Tensorflow发布了JS版本之后,这一领域又引起了我的注意。在python垄断的时代,发布JS工具库不就是意味着我们前端工程师也可以参与其中。可以参考JS图像识别项目(https://github.com/jerryOnlyZRJ/image-regression)。 随着JS引擎的计算能力不断增强,人工智能领域的不断发展,可以预见的是,在不久的将来,肯定能有一些简单的算法可以被移植到用户前端执行,这样既能减少请求,又能分担后端压力。这一切并不是无稽之谈,为什么tensorflow.js会应运而生,正是因为JS的社区在不断壮大,JS这款便捷的语言也在得到更为普遍的使用。 还是应征了那句老话:技术从来不会受限于语言,受限你的,永远只是思想。 谈到前端前端框架,目前有 Vue、React、Svelte、Angular (按GITHUB排行榜);初次之外,各种平台的框架也都层次不穷,以小程序为例就有taro、omi、uniapp、mpx、mpvue等等,前端轮子多,总有一款适合你。但是探究和比较框架已经没有实际意义了,狼叔在2019年的D2论坛上的演讲,其中那句话令我记忆深刻,“前端的纷争已经结束,接下来的重点是提效”,现在已经不是争论三驾马车和flutter框架之争、性能之争,而是如何运用前端技术去发力、提高生成效能。因为最终我们的生产成果需要接收社会大众的检验,学好技术是过程,做好产品是结果,不该把时间放在没有效率的事上。 保持学习的热情,保持编码的的热情,无论你现在是写算法亦或是写业务,术业有专职。 前端面试指南 针对招聘需求可能会要求的一些技术栈,我整理一些常用的前端框架和技能,但是很不够全面,比如canvs、webgl、threeJs、phaser、pixi等等绘图、可视化相关的东西都没有列举到,仅供大家参考。 2020谁的码生不迷茫 码生如佛,弓象征着码生的曲曲折折,一撇是那曾经走的弯路,那一竖是将要走的路,2020年,希望大家大道至简,学会权衡,懂得舍弃,持续进化,抓住机遇。共勉~

问问小秘 2020-03-23 10:08:43 0 浏览量 回答数 0

问题

从一道面试题谈谈一线大厂码农应该具备的基本能力 7月16日 【今日算法】

游客ih62co2qqq5ww 2020-07-22 13:45:47 118 浏览量 回答数 1

回答

木心的《从前慢》里说: 记得早先少年时 大家诚诚恳恳 说一句 是一句 …… 从前的日色变得慢 车,马,邮件都慢 一生只够爱一个人 从前的锁也好看 钥匙精美有样子 你锁了 人家就懂了 木心怀念着过去那个通过邮件传递信息的简单时代。 当下的网络时代虽然瞬息万变,但传递信息也是一样的“说一句,是一句”,“你 锁了,人家就懂了”。 小程序经常需要往服务器传递数据或者从服务器拉取信息。 当用户通过小程序加载服务器传来的信息时,整个网络过程如下: 1. 用户通过小程序向服务器发出 GET 请求, 2. 服务器发送一个响应,响应信息包含一个数据文件。 上面的流程也许过于简化,其实用户与服务器之间不可能面对面直接通话,因为它 们相隔不是很近,甚至服务器是在浏览器的千里之外,而客户端浏览器不可能直通 服务器。 每一次的网络请求,小程序传递给服务器的信息,中间经过多重的信息转达。同理 服务器回应小程序的响应也是同样的路径。 通俗点说,就是传纸条的原理。写字条的同学需要把字条递给旁边第一个同学,然 后第二个同学递给第三个同学,以此类推,一直传递到最后的信息接收者。 让我们看看,在传递字条的过程中,如果信息发出者想要给信息最末尾的接受者告 白,会发生什么呢? 在HTTP 状态下,传递者都可以打开字条,查看里面的内容。而且发送信息者无法知道传输路径,一旦发生信息窃取,甚至不知道是谁窃取的。 还是就是当信息落入心怀不轨的人手中,或者篡改信息内容,其后果不可设想。比如,把“你喜欢我吗?”篡改成“你不喜欢我吗?”。 为了避免这些情况发生,HTTP 安全版本应运而生,即HTTPS。通过HTTPS,传送的每次信息都被加上一个锁。 该锁配套的公钥和密钥仅小程序和服务器知道,其他传递者无法获取。因此,无论客户端发送的信息经过多个路由器,他人都无法读取信息内容。客户端发送初始信息到服务器时,在信息内容中包含服务器的名称(在名为“服务器名称指示”的字段中)。而服务器运行商可以在同一台计算机上运行多个站点, 因此运行商可以跟踪到客户端的访问轨迹。虽然初始的信息已设置了加密,但是初始请求是仍未加密的。这就是通过小程序my.request 安全传递告白信息的故事。本节将介绍如何使用my.request API 实现网络请求,并介绍一些使用注意事项。版本要求:基础库1.11.0 或更高版本;支付宝客户端10.1.32 或更高版本,若版本较低,建议做兼容处理。 my.request 目前只支持HTTPS 协议的请求。 使用说明:  请预先在 支付宝小程序管理中心 > 小程序详情 > 设置 > 开发设置 > 服务器域名白名单 中配置域名白名单。小程序在以下 API 调用时只能与白名单中的域名进行通讯:HTTP 请 求(my.request)、上传文件(my.uploadFile)、下载文件(my.downloadFile)和 WebSocket(my.connectSocket)。  添加服务器域名白名单后,需要重新打包上传生成体验版,服务器域名才会生效。  在 IDE 上进行调试时,请使用真机预览调试。  支付宝客户端已不再维护 my.httpRequest,建议使用 my.request。另外,钉钉客户端尚 不支持 my.request。若在钉钉客户端开发小程序,则需要使用 my.httpRequest。 扫码体验 重要:  小程序开发过程中,可在开发工具内 详情 > 域名信息 > 忽略 httpRequest 域名合法性 检查 中选择是否忽略域名合法性检查,如果选择忽略,则在模拟器、预览以及真机调试场 景不会校验域名合法性,但小程序上线前必须确保通讯域名在白名单内,否则在正式版本无 法调用。  my.request 的请求头默认值为 {'content-type': 'application/json'},而不是{'contenttype': 'application/x-www-form-urlencoded'}。此外,请求头对象里面的 key 和 value 必须是 String 类型。 示例代码 my.request({ url: 'https://httpbin.org/post', method: 'POST', data: { from: '支付宝', production: 'AlipayJSAPI', }, dataType: 'json', success: function(res) { my.alert({content: 'success'}); }, fail: function(res) { my.alert({content: 'fail'}); }, complete: function(res) { my.hideLoading(); my.alert({content: 'complete'}); } }); // dataType 为 base64 示例 my.request({ url: 'https://gw.alipayobjects.com/mdn/miniapp_de/afts/img/A*G1kWSJbe2zEAAAAA AAAAAABjARQnAQ', method: 'GET', dataType: 'base64', success: (resp) => { console.log('resp data length', resp.data.length); console.log('resp data', resp.data); // 返回格式类似于: data:image/png;base64,iVBORw0KG... }, fail: (err) => { console.log('error', err); }, }) 入参 Object 类型,属性如下: 属性 类型 必填 描述 url String 是 目标服务器 URL。 headers Object 否 设置请求的 HTTP 头对象,默认 {'content-type': 'application/json'},该对象里面 的 key 和 value 必须是 String 类型。 method String 否 默认 GET,目前支持 GET/POST/PUT/DELETE。 data Object 否 详见 data 参数说明。 timeout Number 否 超时时间,单位 ms,默认 30000。 dataType String 否 期望返回的数据格式,默认 JSON,支持 JSON、text、 base64、arraybuffer (10.1.70 版本开始支持) 。 success Function 否 调用成功的回调函数。 fail Function 否 调用失败的回调函数。 complete Function 否 调用结束的回调函数(调用成功、 失败都会执行)。 data 参数说明 传给服务器的数据最终会是 String 类型,如果 data 不是 String 类型,会被 转换成 String 。转换规则如下:  若方法为 GET,会将数据转换成 query string: encodeURIComponent(k)=encodeURIComponent(v)&encodeURIComponent(k)=enc odeURIComponent(v)...  若方法为 POST 且 headers['content-type'] 为 application/json ,会对数据进行 JSON 序列化  若方法为 POST 且 headers['content-type'] 为 application/x-www-formurlencoded ,会将数据转换成 query string: encodeURIComponent(k)=encodeURIComponent(v)&encodeURIComponent(k)=enc odeURIComponent(v)... success 回调函数 入参为 Object 类型,属性如下: 属性 类型 描述 data String 响应数据,格式取决于请求时的 dataType 参数, 如果 dataType 值为 base64 时,返回的是符合 data URI scheme 规范的内容字符串。 status Number 响应码。 headers Object 响应头。 返回值 RequestTask 网络请求任务对象。调用 my.request 后返回的请求对象。 RequestTask.abort() 中断请求任务。 示例代码 const task = my.request({url: 'https://httpbin.org/post'}) task.abort(); “抱歉,不是我的菜”:小程序扫码点餐化解尴 尬 月上柳梢头,人约黄昏后。 周五到了,小心翼翼约她出来吃晚饭,她欣然应约。 餐厅位于徐汇区闹中取静的华山路,法式梧桐的点缀让餐厅更显典雅,也更富有异 国情调。踏入餐厅,灯光是橘色的,餐具是蓝的,桌椅也是蓝的,让人恍惚之间有 到了爱琴海边的错觉,唯美的装修风格、充满欧洲风味的精致美食,处处洋溢着地 中海风情,真浪漫啊。 她翩翩而至,裙裾飞扬。 见到她我脸红了。我紧张地问她要吃些什么,又手忙脚乱地叫来服务员点完了菜, 脸上冒出了小汗珠。 窗外的小雨滴滴答答,窗内的我们显得格外安静。 我鼓起勇气,打破沉默,小声问道:“你……你对我印象如何?” “抱歉,不是我的菜……” 此刻,我如同五雷轰顶,只觉天旋地转,眼前华光溢彩的餐厅瞬间变得黯淡了。 “你是不是点错菜了?还是上错菜了呢?”她指着桌上的法式田螺和奶油蘑菇汤, 瞪大了眼睛问我。旁边站着满脸疑惑的上菜员。 如何化解点错菜的尴尬呢?这时就需要使用支付宝小程序扫码点餐的功能了。 为了让用户减少输入,我们可以把复杂的信息编码成一个二维码,利用 my.scan API 调起支付宝扫一扫,用户扫码之后,my.scan 的 success 回调会收到这个 二维码所对应的字符串信息。 例如餐厅点餐的小程序,我们给餐厅中每个餐桌编号 1-100 号,把这个数字编码 到二维码中,扫码获得编号之后,就可以知道是哪一桌点的菜,大大提高点餐体验 和效率。 //page.js Page({ // 点击“扫码订餐”的按钮,触发 tapScan 回调 tapScan: function() { // 调用 my.login 获取微信登录凭证 my.scanCode({ success: function(res) { var num = res.result // 获取到的 num 就是餐桌的编号 } }) } }) 还有很多场景可以结合支付宝 App 扫码能力做到很好的体验,例如通过扫商品 上的一维码做一个商品展示的小程序;通过扫共享单车上的二维码去开启单车。我 们可以多思考如何利用这个扫码能力去替代一些繁琐的输入操作,让我们的小程序 变得更加便捷。 示例代码 // API-DEMO page/API/scan-code/scan-code.json { "defaultTitle": "Scan" <!-- API-DEMO page/API/scan-code/scan-code.axml--> <view class="page"> <view class="page-section"> <form onSubmit="scanCode"> <view> <button type="primary" onTap="scan">扫码</button> </view> </form> </view> </view> // API-DEMO page/API/scan-code/scan-code.js Page({ scan() { my.scan({ type: 'qr', success: (res) => { my.alert({ title: res.code }); }, }); } }) 入参 Object 类型,属性如下: 内容来源:https://developer.aliyun.com/article/756818?spm=a2c6h.12873581.0.dArticle756818.26162b70Su1GZy&groupCode=tech_library

KaFei 2020-04-27 15:46:55 0 浏览量 回答数 0

问题

什么是B+树 6月1日【今日算法】

游客ih62co2qqq5ww 2020-06-01 14:50:52 1 浏览量 回答数 1

回答

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下: 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner,也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说,如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK(AccessKey)有三种类型,具体如下: 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK,每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对(AccessKeyId和AccessKeySecret)。 用户可以登录AccessKey管理控制台,申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态,可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态,不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM,您可以集中管理您的用户(比如员工、系统或应用程序),以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的,并且这些账号下不能拥有实际的任何资源,所有资源都属于主账号。 STS账号AccessKey STS(Security Token Service)是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式: AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时,其身份验证的实现如下: 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后,通过AccessKeyId找到对应的AccessKeySecret,以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则,OSS将拒绝处理这次请求,并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK,配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问,OSS提供了多种权限控制,主要有: Bucket级别权限 Object级别权限 账号级别权限(RAM) 临时账号权限(STS) Bucket级别权限 Bucket权限类型 OSS提供ACL(Access Control List)权限控制方法,OSS ACL提供Bucket级别的权限访问控制,Bucket目前有三种访问权限:public-read-write,public-read和private,它们的含义如下: 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人(包括匿名访问)都可以对该Bucket中的Object进行读/写/删除操作;所有这些操作产生的费用由该Bucket的Owner承担,请慎用该权限。 public-read 公共读,私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作;任何人(包括匿名访问)可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作;其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考: API:Put BucketACL SDK:Java SDK-设置Bucket ACL 控制台:创建Bucket权限设置 API:Get BucketACL SDK:Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限:private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置,这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源,即所有用户拥有对该Object的读写权限。 public-read 公共读,私有写 该ACL表明某个Object是公共读资源,即非Object Owner只有该Object的读权限,而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源,即只有该Object的Owner拥有该Object的读写权限,其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源,即Bucket是什么权限,Object就是什么权限。 说明 如果没有设置Object的权限,即Object的ACL为default,Object的权限和Bucket权限一致。 如果设置了Object的权限,Object的权限大于Bucket权限。举个例子,如果设置了Object的权限是public-read,无论Bucket是什么权限,该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考: API:Put Object ACL SDK:Java SDK-ObjectACL 中设定Object ACL API:Get Object ACL SDK:Java SDK-ObjectACL 中读取Object ACL 账号级别权限(RAM) 使用场景 如果您购买了云资源,您的组织里有多个用户需要使用这些云资源,这些用户只能共享使用您的云账号AccessKey。这里有两个问题: 您的密钥由多人共享,泄露的风险很高。 您无法控制特定用户能访问哪些资源(比如Bucket)的权限。 解决方法:在您的阿里云账号下面,通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号,创建出来的账号被称为子账号,使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情,请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节:RAM和STS授权策略(Policy)配置。 临时账号权限(STS) 使用场景 对于您本地身份系统所管理的用户,比如您的App的用户、您的企业本地账号、第三方App,也有直接访问OSS资源的可能,将这部分用户称为联盟用户。此外,用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户,通过阿里云STS (Security Token Service) 服务为阿里云账号(或RAM用户)提供短期访问权限管理。您不需要透露云账号(或RAM用户)的长期密钥(如登录密码、AccessKey),只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题,访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情,请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可,也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景,涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者,打算使用阿里云OSS服务来保存App的终端用户数据,并且要保证每个App用户之间的数据隔离,防止一个App用户获取到其它App用户的数据。 方式一:使用AppServer来做数据中转和数据隔离如上图所示,您需要开发一个AppServer。只有AppServer能访问云服务,ClientApp的每次读写数据都需要通过AppServer,AppServer来保证不同用户数据的隔离访问。 对于该种使用方式,使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号(主账号)的密钥访问OSS,避免出现安全问题。 方式二:使用STS让用户直接访问OSS STS方案描述如下图所示:方案的详细描述如下: App用户登录。App用户和云账号无关,它是App的终端用户,AppServer支持App用户登录。对于每个有效的App用户来说,需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌(SecurityToken)。在调用STS之前,AppServer需要确定App用户的最小访问权限(用Policy语法描述)以及授权的过期时间。然后通过扮演角色(AssumeRole)来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证,包括一个安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时,ClientApp需要向AppServer申请新的有效访问凭证。比如,访问凭证有效期为1小时,那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证,并会依赖STS服务来验证访问凭证,正确响应用户请求。 RAM和STS授权策略(Policy)配置 对于RAM或者STS授权中使用Policy,详细规则如下。 示例 先看下面的一个Policy示例: { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy,用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement(一条Policy当中可以有多条Statement)。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户,并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk,源IP为192.168.0.1的时候鉴权才能通过,被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket(ListObjects)的时候起作用的,关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本,本文档中sw2q的配置方式,设置为1。 Statement 通过Statement描述授权语义,其中可以根据业务场景包含多条语义,每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查,所有匹配成功的Statement会根据Effect的设置不同分为通过(Allow)、禁止(Deny),其中禁止(Deny)的优先。如果匹配成功的都为通过,该条请求即鉴权通过。如果匹配成功有一条禁止,或者没有任何条目匹配成功,该条请求被禁止访问。 Action Action分为三大类:Service级别操作,对应的是GetService操作,用来列出所有属于该用户的Bucket列表。 Bucket级别操作,对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作,操作的对象是Bucket,它们的名称和相应的接口名称一一对应。 Object级别操作,分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload,操作对象是Object。 如想授权某一类的Object的操作,可以选择这几种的一种或几种。另外,所有的Action前面都必须加上oss:,如上面例子所示。Action是一个列表,可以有多个Action。具体的Action和API接口的对应关系如下: Service级别 API Action GetService(ListBuckets) oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket(ListObjects) oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源(支持*通配),resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name},即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表,可以有多个Resource。其中的region字段暂时不做支持,设置为*。 Effect Effect代表本条的Statement的授权的结果,分为Allow和Deny,分别指代通过和禁止。多条Statement同时匹配成功时,禁止(Deny)的优先级更高。 例如,期望禁止用户对某一目录进行删除,但对于其他文件有全部权限: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件,上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下: condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip,支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例,可以参考教程示例:控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具,请单击这里。 最佳实践 RAM和STS使用指南

2019-12-01 23:12:47 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下: 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner,也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说,如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK(AccessKey)有三种类型,具体如下: 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK,每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对(AccessKeyId和AccessKeySecret)。 用户可以登录AccessKey管理控制台,申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态,可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态,不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM,您可以集中管理您的用户(比如员工、系统或应用程序),以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的,并且这些账号下不能拥有实际的任何资源,所有资源都属于主账号。 STS账号AccessKey STS(Security Token Service)是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式: AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时,其身份验证的实现如下: 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后,通过AccessKeyId找到对应的AccessKeySecret,以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则,OSS将拒绝处理这次请求,并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK,配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问,OSS提供了多种权限控制,主要有: Bucket级别权限 Object级别权限 账号级别权限(RAM) 临时账号权限(STS) Bucket级别权限 Bucket权限类型 OSS提供ACL(Access Control List)权限控制方法,OSS ACL提供Bucket级别的权限访问控制,Bucket目前有三种访问权限:public-read-write,public-read和private,它们的含义如下: 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人(包括匿名访问)都可以对该Bucket中的Object进行读/写/删除操作;所有这些操作产生的费用由该Bucket的Owner承担,请慎用该权限。 public-read 公共读,私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作;任何人(包括匿名访问)可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作;其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考: API:Put BucketACL SDK:Java SDK-设置Bucket ACL 控制台:创建Bucket权限设置 API:Get BucketACL SDK:Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限:private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置,这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源,即所有用户拥有对该Object的读写权限。 public-read 公共读,私有写 该ACL表明某个Object是公共读资源,即非Object Owner只有该Object的读权限,而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源,即只有该Object的Owner拥有该Object的读写权限,其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源,即Bucket是什么权限,Object就是什么权限。 说明 如果没有设置Object的权限,即Object的ACL为default,Object的权限和Bucket权限一致。 如果设置了Object的权限,Object的权限大于Bucket权限。举个例子,如果设置了Object的权限是public-read,无论Bucket是什么权限,该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考: API:Put Object ACL SDK:Java SDK-ObjectACL 中设定Object ACL API:Get Object ACL SDK:Java SDK-ObjectACL 中读取Object ACL 账号级别权限(RAM) 使用场景 如果您购买了云资源,您的组织里有多个用户需要使用这些云资源,这些用户只能共享使用您的云账号AccessKey。这里有两个问题: 您的密钥由多人共享,泄露的风险很高。 您无法控制特定用户能访问哪些资源(比如Bucket)的权限。 解决方法:在您的阿里云账号下面,通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号,创建出来的账号被称为子账号,使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情,请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节:RAM和STS授权策略(Policy)配置。 临时账号权限(STS) 使用场景 对于您本地身份系统所管理的用户,比如您的App的用户、您的企业本地账号、第三方App,也有直接访问OSS资源的可能,将这部分用户称为联盟用户。此外,用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户,通过阿里云STS (Security Token Service) 服务为阿里云账号(或RAM用户)提供短期访问权限管理。您不需要透露云账号(或RAM用户)的长期密钥(如登录密码、AccessKey),只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题,访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情,请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可,也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景,涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者,打算使用阿里云OSS服务来保存App的终端用户数据,并且要保证每个App用户之间的数据隔离,防止一个App用户获取到其它App用户的数据。 方式一:使用AppServer来做数据中转和数据隔离如上图所示,您需要开发一个AppServer。只有AppServer能访问云服务,ClientApp的每次读写数据都需要通过AppServer,AppServer来保证不同用户数据的隔离访问。 对于该种使用方式,使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号(主账号)的密钥访问OSS,避免出现安全问题。 方式二:使用STS让用户直接访问OSS STS方案描述如下图所示:方案的详细描述如下: App用户登录。App用户和云账号无关,它是App的终端用户,AppServer支持App用户登录。对于每个有效的App用户来说,需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌(SecurityToken)。在调用STS之前,AppServer需要确定App用户的最小访问权限(用Policy语法描述)以及授权的过期时间。然后通过扮演角色(AssumeRole)来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证,包括一个安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时,ClientApp需要向AppServer申请新的有效访问凭证。比如,访问凭证有效期为1小时,那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证,并会依赖STS服务来验证访问凭证,正确响应用户请求。 RAM和STS授权策略(Policy)配置 对于RAM或者STS授权中使用Policy,详细规则如下。 示例 先看下面的一个Policy示例: { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy,用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement(一条Policy当中可以有多条Statement)。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户,并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk,源IP为192.168.0.1的时候鉴权才能通过,被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket(ListObjects)的时候起作用的,关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本,本文档中sw2q的配置方式,设置为1。 Statement 通过Statement描述授权语义,其中可以根据业务场景包含多条语义,每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查,所有匹配成功的Statement会根据Effect的设置不同分为通过(Allow)、禁止(Deny),其中禁止(Deny)的优先。如果匹配成功的都为通过,该条请求即鉴权通过。如果匹配成功有一条禁止,或者没有任何条目匹配成功,该条请求被禁止访问。 Action Action分为三大类:Service级别操作,对应的是GetService操作,用来列出所有属于该用户的Bucket列表。 Bucket级别操作,对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作,操作的对象是Bucket,它们的名称和相应的接口名称一一对应。 Object级别操作,分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload,操作对象是Object。 如想授权某一类的Object的操作,可以选择这几种的一种或几种。另外,所有的Action前面都必须加上oss:,如上面例子所示。Action是一个列表,可以有多个Action。具体的Action和API接口的对应关系如下: Service级别 API Action GetService(ListBuckets) oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket(ListObjects) oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源(支持*通配),resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name},即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表,可以有多个Resource。其中的region字段暂时不做支持,设置为*。 Effect Effect代表本条的Statement的授权的结果,分为Allow和Deny,分别指代通过和禁止。多条Statement同时匹配成功时,禁止(Deny)的优先级更高。 例如,期望禁止用户对某一目录进行删除,但对于其他文件有全部权限: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件,上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下: condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip,支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例,可以参考教程示例:控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具,请单击这里。 最佳实践 RAM和STS使用指南

2019-12-01 23:12:47 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下: 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner,也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说,如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK(AccessKey)有三种类型,具体如下: 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK,每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对(AccessKeyId和AccessKeySecret)。 用户可以登录AccessKey管理控制台,申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态,可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态,不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM,您可以集中管理您的用户(比如员工、系统或应用程序),以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的,并且这些账号下不能拥有实际的任何资源,所有资源都属于主账号。 STS账号AccessKey STS(Security Token Service)是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式: AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时,其身份验证的实现如下: 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后,通过AccessKeyId找到对应的AccessKeySecret,以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则,OSS将拒绝处理这次请求,并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK,配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问,OSS提供了多种权限控制,主要有: Bucket级别权限 Object级别权限 账号级别权限(RAM) 临时账号权限(STS) Bucket级别权限 Bucket权限类型 OSS提供ACL(Access Control List)权限控制方法,OSS ACL提供Bucket级别的权限访问控制,Bucket目前有三种访问权限:public-read-write,public-read和private,它们的含义如下: 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人(包括匿名访问)都可以对该Bucket中的Object进行读/写/删除操作;所有这些操作产生的费用由该Bucket的Owner承担,请慎用该权限。 public-read 公共读,私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作;任何人(包括匿名访问)可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作;其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考: API:Put BucketACL SDK:Java SDK-设置Bucket ACL 控制台:创建Bucket权限设置 API:Get BucketACL SDK:Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限:private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置,这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源,即所有用户拥有对该Object的读写权限。 public-read 公共读,私有写 该ACL表明某个Object是公共读资源,即非Object Owner只有该Object的读权限,而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源,即只有该Object的Owner拥有该Object的读写权限,其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源,即Bucket是什么权限,Object就是什么权限。 说明 如果没有设置Object的权限,即Object的ACL为default,Object的权限和Bucket权限一致。 如果设置了Object的权限,Object的权限大于Bucket权限。举个例子,如果设置了Object的权限是public-read,无论Bucket是什么权限,该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考: API:Put Object ACL SDK:Java SDK-ObjectACL 中设定Object ACL API:Get Object ACL SDK:Java SDK-ObjectACL 中读取Object ACL 账号级别权限(RAM) 使用场景 如果您购买了云资源,您的组织里有多个用户需要使用这些云资源,这些用户只能共享使用您的云账号AccessKey。这里有两个问题: 您的密钥由多人共享,泄露的风险很高。 您无法控制特定用户能访问哪些资源(比如Bucket)的权限。 解决方法:在您的阿里云账号下面,通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号,创建出来的账号被称为子账号,使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情,请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节:RAM和STS授权策略(Policy)配置。 临时账号权限(STS) 使用场景 对于您本地身份系统所管理的用户,比如您的App的用户、您的企业本地账号、第三方App,也有直接访问OSS资源的可能,将这部分用户称为联盟用户。此外,用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户,通过阿里云STS (Security Token Service) 服务为阿里云账号(或RAM用户)提供短期访问权限管理。您不需要透露云账号(或RAM用户)的长期密钥(如登录密码、AccessKey),只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题,访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情,请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可,也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景,涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者,打算使用阿里云OSS服务来保存App的终端用户数据,并且要保证每个App用户之间的数据隔离,防止一个App用户获取到其它App用户的数据。 方式一:使用AppServer来做数据中转和数据隔离如上图所示,您需要开发一个AppServer。只有AppServer能访问云服务,ClientApp的每次读写数据都需要通过AppServer,AppServer来保证不同用户数据的隔离访问。 对于该种使用方式,使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号(主账号)的密钥访问OSS,避免出现安全问题。 方式二:使用STS让用户直接访问OSS STS方案描述如下图所示:方案的详细描述如下: App用户登录。App用户和云账号无关,它是App的终端用户,AppServer支持App用户登录。对于每个有效的App用户来说,需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌(SecurityToken)。在调用STS之前,AppServer需要确定App用户的最小访问权限(用Policy语法描述)以及授权的过期时间。然后通过扮演角色(AssumeRole)来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证,包括一个安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时,ClientApp需要向AppServer申请新的有效访问凭证。比如,访问凭证有效期为1小时,那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证,并会依赖STS服务来验证访问凭证,正确响应用户请求。 RAM和STS授权策略(Policy)配置 对于RAM或者STS授权中使用Policy,详细规则如下。 示例 先看下面的一个Policy示例: { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy,用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement(一条Policy当中可以有多条Statement)。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户,并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk,源IP为192.168.0.1的时候鉴权才能通过,被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket(ListObjects)的时候起作用的,关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本,本文档中sw2q的配置方式,设置为1。 Statement 通过Statement描述授权语义,其中可以根据业务场景包含多条语义,每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查,所有匹配成功的Statement会根据Effect的设置不同分为通过(Allow)、禁止(Deny),其中禁止(Deny)的优先。如果匹配成功的都为通过,该条请求即鉴权通过。如果匹配成功有一条禁止,或者没有任何条目匹配成功,该条请求被禁止访问。 Action Action分为三大类:Service级别操作,对应的是GetService操作,用来列出所有属于该用户的Bucket列表。 Bucket级别操作,对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作,操作的对象是Bucket,它们的名称和相应的接口名称一一对应。 Object级别操作,分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload,操作对象是Object。 如想授权某一类的Object的操作,可以选择这几种的一种或几种。另外,所有的Action前面都必须加上oss:,如上面例子所示。Action是一个列表,可以有多个Action。具体的Action和API接口的对应关系如下: Service级别 API Action GetService(ListBuckets) oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket(ListObjects) oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源(支持*通配),resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name},即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表,可以有多个Resource。其中的region字段暂时不做支持,设置为*。 Effect Effect代表本条的Statement的授权的结果,分为Allow和Deny,分别指代通过和禁止。多条Statement同时匹配成功时,禁止(Deny)的优先级更高。 例如,期望禁止用户对某一目录进行删除,但对于其他文件有全部权限: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件,上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下: condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip,支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例,可以参考教程示例:控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具,请单击这里。 最佳实践 RAM和STS使用指南

2019-12-01 23:12:47 0 浏览量 回答数 0

回答

如大家所知道的,Mysql目前主要有以下几种索引类型:FULLTEXT,HASH,BTREE,RTREE。 那么,这几种索引有什么功能和性能上的不同呢? FULLTEXT 即为全文索引,目前只有MyISAM引擎支持。其可以在CREATE TABLE ,ALTER TABLE ,CREATE INDEX 使用,不过目前只有 CHAR、VARCHAR ,TEXT 列上可以创建全文索引。值得一提的是,在数据量较大时候,现将数据放入一个没有全局索引的表中,然后再用CREATE INDEX创建FULLTEXT索引,要比先为一张表建立FULLTEXT然后再将数据写入的速度快很多。 全文索引并不是和MyISAM一起诞生的,它的出现是为了解决WHERE name LIKE “%word%"这类针对文本的模糊查询效率较低的问题。在没有全文索引之前,这样一个查询语句是要进行遍历数据表操作的,可见,在数据量较大时是极其的耗时的,如果没有异步IO处理,进程将被挟持,很浪费时间,当然这里不对异步IO作进一步讲解,想了解的童鞋,自行谷哥。 全文索引的使用方法并不复杂: 创建ALTER TABLE table ADD INDEX FULLINDEX USING FULLTEXT(cname1[,cname2…]); 使用SELECT * FROM table WHERE MATCH(cname1[,cname2…]) AGAINST ('word' MODE ); 其中, MODE为搜寻方式(IN BOOLEAN MODE ,IN NATURAL LANGUAGE MODE ,IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION / WITH QUERY EXPANSION)。 关于这三种搜寻方式,愚安在这里也不多做交代,简单地说,就是,布尔模式,允许word里含一些特殊字符用于标记一些具体的要求,如+表示一定要有,-表示一定没有,*表示通用匹配符,是不是想起了正则,类似吧;自然语言模式,就是简单的单词匹配;含表达式的自然语言模式,就是先用自然语言模式处理,对返回的结果,再进行表达式匹配。 对搜索引擎稍微有点了解的同学,肯定知道分词这个概念,FULLTEXT索引也是按照分词原理建立索引的。西文中,大部分为字母文字,分词可以很方便的按照空格进行分割。但很明显,中文不能按照这种方式进行分词。那又怎么办呢?这个向大家介绍一个Mysql的中文分词插件Mysqlcft,有了它,就可以对中文进行分词,想了解的同学请移步Mysqlcft,当然还有其他的分词插件可以使用。 HASH Hash这个词,可以说,自打我们开始码的那一天起,就开始不停地见到和使用到了。其实,hash就是一种(key=>value)形式的键值对,如数学中的函数映射,允许多个key对应相同的value,但不允许一个key对应多个value。正是由于这个特性,hash很适合做索引,为某一列或几列建立hash索引,就会利用这一列或几列的值通过一定的算法计算出一个hash值,对应一行或几行数据(这里在概念上和函数映射有区别,不要混淆)。在java语言中,每个类都有自己的hashcode()方法,没有显示定义的都继承自object类,该方法使得每一个对象都是唯一的,在进行对象间equal比较,和序列化传输中起到了很重要的作用。hash的生成方法有很多种,足可以保证hash码的唯一性,例如在MongoDB中,每一个document都有系统为其生成的唯一的objectID(包含时间戳,主机散列值,进程PID,和自增ID)也是一种hash的表现。额,我好像扯远了-_-! 由于hash索引可以一次定位,不需要像树形索引那样逐层查找,因此具有极高的效率。那为什么还需要其他的树形索引呢? 在这里愚安就不自己总结了。引用下园子里其他大神的文章:来自 14的路 的MySQL的btree索引和hash索引的区别 (1)Hash 索引仅仅能满足"=","IN"和"<=>"查询,不能使用范围查询。 由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值,所以它只能用于等值的过滤,不能用于基于范围的过滤,因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系,并不能保证和Hash运算前完全一样。 (2)Hash 索引无法被用来避免数据的排序操作。 由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值,而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样,所以数据库无法利用索引的数据来避免任何排序运算; (3)Hash 索引不能利用部分索引键查询。 对于组合索引,Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值,而不是单独计算 Hash 值,所以通过组合索引的前面一个或几个索引键进行查询的时候,Hash 索引也无法被利用。 (4)Hash 索引在任何时候都不能避免表扫描。 前面已经知道,Hash 索引是将索引键通过 Hash 运算之后,将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中,由于不同索引键存在相同 Hash 值,所以即使取满足某个 Hash 键值的数据的记录条数,也无法从 Hash 索引中直接完成查询,还是要通过访问表中的实际数据进行相应的比较,并得到相应的结果。 (5)Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。 对于选择性比较低的索引键,如果创建 Hash 索引,那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦,会浪费多次表数据的访问,而造成整体性能低下。 愚安我稍作补充,讲一下HASH索引的过程,顺便解释下上面的第4,5条: 当我们为某一列或某几列建立hash索引时(目前就只有MEMORY引擎显式地支持这种索引),会在硬盘上生成类似如下的文件: hash值 存储地址 1db54bc745a1 77#45b5 4bca452157d4 76#4556,77#45cc… … hash值即为通过特定算法由指定列数据计算出来,磁盘地址即为所在数据行存储在硬盘上的地址(也有可能是其他存储地址,其实MEMORY会将hash表导入内存)。 这样,当我们进行WHERE age = 18 时,会将18通过相同的算法计算出一个hash值==>在hash表中找到对应的储存地址==>根据存储地址取得数据。 所以,每次查询时都要遍历hash表,直到找到对应的hash值,如(4),数据量大了之后,hash表也会变得庞大起来,性能下降,遍历耗时增加,如(5)。 BTREE BTREE索引就是一种将索引值按一定的算法,存入一个树形的数据结构中,相信学过数据结构的童鞋都对当初学习二叉树这种数据结构的经历记忆犹新,反正愚安我当时为了软考可是被这玩意儿好好地折腾了一番,不过那次考试好像没怎么考这个。如二叉树一样,每次查询都是从树的入口root开始,依次遍历node,获取leaf。 BTREE在MyISAM里的形式和Innodb稍有不同 在 Innodb里,有两种形态:一是primary key形态,其leaf node里存放的是数据,而且不仅存放了索引键的数据,还存放了其他字段的数据。二是secondary index,其leaf node和普通的BTREE差不多,只是还存放了指向主键的信息. 而在MyISAM里,主键和其他的并没有太大区别。不过和Innodb不太一样的地方是在MyISAM里,leaf node里存放的不是主键的信息,而是指向数据文件里的对应数据行的信息. RTREE RTREE在mysql很少使用,仅支持geometry数据类型,支持该类型的存储引擎只有MyISAM、BDb、InnoDb、NDb、Archive几种。 相对于BTREE,RTREE的优势在于范围查找. 各种索引的使用情况 (1)对于BTREE这种Mysql默认的索引类型,具有普遍的适用性 (2)由于FULLTEXT对中文支持不是很好,在没有插件的情况下,最好不要使用。其实,一些小的博客应用,只需要在数据采集时,为其建立关键字列表,通过关键字索引,也是一个不错的方法,至少愚安我是经常这么做的。 (3)对于一些搜索引擎级别的应用来说,FULLTEXT同样不是一个好的处理方法,Mysql的全文索引建立的文件还是比较大的,而且效率不是很高,即便是使用了中文分词插件,对中文分词支持也只是一般。真要碰到这种问题,Apache的Lucene或许是你的选择。 (4)正是因为hash表在处理较小数据量时具有无可比拟的素的优势,所以hash索引很适合做缓存(内存数据库)。如mysql数据库的内存版本Memsql,使用量很广泛的缓存工具Mencached,NoSql数据库redis等,都使用了hash索引这种形式。当然,不想学习这些东西的话Mysql的MEMORY引擎也是可以满足这种需求的。 (5)至于RTREE,愚安我至今还没有使用过,它具体怎么样,我就不知道了。有RTREE使用经历的同学,到时可以交流下! 答案来源于网络

养狐狸的猫 2019-12-02 02:18:32 0 浏览量 回答数 0

回答

简单解释下: 第三方登陆是建立在信任的基础上的。以微博为例,微博账号密码可以用来登陆OSCHINA,但这个登陆过程还是在微博进行,在OSCHINA上点击微博登陆会跳到微博登陆页面(authorize)并传递一些参数(appid、appkey)过去告诉微博你是从OSCHINA过来的,登陆成功后微博会访问OSCHINA的一个URL(callback_url)并传递相关信息(access_token),通过它可以拿到一个可以唯一的确认用户身份的字段(uid),这时OSCHINA就会直接把此用户的状态更改为已登录而不需要用户名密码。 账号绑定时所要做的事情就是拿到前面说的可以唯一的确认用户身份的字段(一般是uid)并保存到数据库,这样用户在微博登陆完成后微博访问OSCHINA的callback_url时OSCHINA就可以通过它来确定要登陆的是哪个用户。 真实情况下的过程要比上面描述的复杂点,一般都是使用OpenID或OAuth2协议,新浪微博使用的是OAuth2。想了解具体细节,可以自己搜索相关资料,这部分资料还是挺多的。 OpenID是专门为第三方登陆开发的协议。而OAuth2则更强大些,不仅可以做第三方登陆,还可以用来做开放平台,控制开放API接口的使用。 OSCHINA的OpenID模块代码是已经开源了的,地址:http://www.oschina.net/code/snippet_12_13361 ######回复 @tsl0922 : session啊,不错的选择,谢谢了 哈哈…………开心######回复 @孙德彪 : OSC目前是把一些用户不可修改的参数临时存到session中,用户可以修改的通过URL传到页面。token是带有效期的,所以不能存数据库,得每次登陆重新获取。具体实现可以看已开源的OpenID模块源码。######再次打扰你下。使用第三方帐户注册第一次登录的时候,会跳转到一个让用户填写os的email和用户信息的页面,添加成功后整个流程注册成功;请问跳转url里带的第三方帐户信息的参数,还有第三方的token等信息,你们是通过url传递过来的吗?这个事务的流程,能方便说下吗? 我现在的做法是将第三方的所有需要入库的参数都通过url传递过来的,也不知道还有没有其他办法来实现这个事务,谢谢######回复 @孙德彪 : 要设置最佳答案哦######明白了,很感谢###### @tsl0922######加个QQ登陆吧###### @红薯 谢谢######回复 @孙德彪 : 我在帮你呼叫他######红薯大哥, 需要@ 这个人,才能提问吗? 我在他的空间,没有找到答案呢######需要第三方的api..百度一下有很多。没什么技术含量的######回复 @钟晓骏 : 当然,一般用到第三方的东西,第三方都会有对应的api接口的。下载的接口,里面也有各种语言的示例。看看就会明白######api 这一层,我当然知道了, 就是困惑 问题中 ps 中的几个步骤,呵呵######与银行和支付宝那些支付的 做对接呢? 调用他们的接口吗?######开放平台的网站连接?

kun坤 2020-06-06 14:53:39 0 浏览量 回答数 0

回答

转自:思否 本文作者:Michael van der Gulik 原文链接:《Why WebAssembly is a big deal》 译者:敖小剑 WebAssembly 是每个程序员都应该关注的技术。WebAssembly 会变得更流行。 WebAssembly 将取代 JavaScript。WebAssembly 将取代 HTML 和 CSS。 WebAssembly 将取代手机应用。WebAssembly 将取代桌面应用。在 10 年内,我保证每个程序员至少需要知道如何使用工具来操作 WebAssembly 并理解它是如何工作的。 你可能会说,“太离谱了!” 好吧,请继续阅读。 什么是 WebAssembly 当前形式的 WebAssembly 是 Web 浏览器的新扩展,可以运行预编译代码…快速地。在 C ++ 中编写了一些小代码,然后使用 Emscripten 编译器将该代码编译为 WebAssembly。通过一些 Javascript 粘合,就可以在 Web 浏览器中调用这一小段代码,例如,运行粒子模拟。 WebAssembly 文件,扩展名为.wasm,本身是包含可执行指令的二进制格式。要使用该文件,必须编写一个运行某些 Javascript 的 HTML 文件来获取、编译和执行 WebAssembly 文件。WebAssembly 文件在基于堆栈的虚拟机上执行,并使用共享内存与其 JavaScript 包装器进行通信。 到目前为止,这似乎并不有趣。它看起来只不过是 JavaScript 的加速器。但是,聪明的读者会对 WebAssembly 可能成为什么有所了解。 WebAssembly 将成为什么? 第一个重要发现是 WebAssembly 是一个安全的沙盒虚拟机。可以从 Internet 运行喜欢的 WebAssembly 代码,而确保它不会接管 PC 或服务器。四个主流 Web 浏览器对它的安全性非常有信心,它已经默认实现并启用了。它的真正安全性还有待观察,但安全性是 WebAssembly 的核心设计目标。 第二个重要发现是 WebAssembly 是一个通用的编译目标。它的原始编译器是一个 C 编译器,这个编译器很好地指示了 WebAssembly 虚拟机的低级和可重定向性。许多编程语言都使用 C 语言编写虚拟机,其他一些语言甚至使用 C 本身作为编译目标。 此时,有人整理了一个可以编译为 WebAssembly 的编程语言列表。这份名单将在未来很多年中继续增长。 WebAssembly 允许使用任何编程语言编写代码,然后让其他人在任何平台上安全地运行该代码,无需安装任何内容。朋友们,这是美好梦想的开始。 部署问题 我们来谈谈如何将软件提供给用户。 为新项目选择编程语言的一个重要因素是如何将项目部署到客户。您的程序员喜欢用 Haskell,Python,Visual Basic 或其他语言编写应用程序,具体取决于他们的喜好。要使用喜欢的语言,他们需要编译应用,制作一些可安装的软件包,并以某种方式将其安装在客户端的计算机上。有许多方法可以提供软件 - 包管理器,可执行安装程序或安装服务,如 Steam,Apple App Store,Google Play 或 Microsoft store。 每一个安装机制都意味着痛苦,从应用商店安装时的轻微疼痛,到管理员要求在他的 PC 上运行一些旧的 COBOL 代码时的集群头痛。 部署是一个问题。对于开发人员和系统管理员来说,部署一直是一个痛点。我们使用的编程语言与我们所针对的平台密切相关。如果大量用户在 PC 或移动设备上,我们使用 HTML 和 Javascript。如果用户是 Apple 移动设备用户,我们使用……呃…… Swift?(我实际上不知道)。如果用户在 Android 设备上,我们使用 Java 或 Kotlin。如果用户在真实计算机上并且愿意处理掉他们的部署问题,那么我们开发人员才能在我们使用的编程语言中有更多选择。 WebAssembly 有可能解决部署问题。 有了 WebAssembly,您可以使用任何编程语言编写应用,只要这些编程语言可以支持 WebAssembly,而应用可以在任何设备和任何具有现代 Web 浏览器的操作系统上运行。 硬件垄断 想购买台式机或笔记本电脑。有什么选择?好吧,有英特尔,有 AMD。多年来一直是双寡头垄断。保持这种双寡头垄断的一个原因是 x86 架构只在这两家公司之间交叉许可,而且通常预编译的代码需要 x86 或 x86-64(也就是 AMD-64)架构。还有其他因素,例如设计世界上最快的 CPU 是一件很艰难但也很昂贵的事情。 WebAssembly 是一种可让您在任何平台上运行代码的技术(之一)。如果它成为下一个风口,硬件市场将变得商品化。应用编译为 WebAssembly,就可以在任何东西上运行 - x86,ARM,RISC-V,SPARC。即便是操作系统市场也会商品化;您所需要的只是一个支持 WebAssembly 的浏览器,以便在硬件可以运行时运行最苛刻的应用程序。 编者注:Second State 研发的专为服务端优化的 WebAssembly 引擎 SSVM 已经可以运行在高通骁龙芯片上。Github 链接:https://github.com/second-sta... 云计算 但等等,还有更多。云计算成为IT经理办公室的流行词已有一段时间,WebAssembly 可以直接迎合它。 WebAssembly 在安全沙箱中执行。可以制作一个容器,它可以在服务器上接受和执行 WebAssembly 模块,而资源开销很小。对于提供的每个服务,无需在虚拟机上运行完整的操作系统。托管提供商只提供对可以上传代码的WebAssembly 容器的访问权限。它可以是一个原始容器,接收 socket 并解析自己的 HTTP 连接,也可以是一个完整的 Web 服务容器,其中 WebAssembly 模块只需要处理预解析的HTTP请求。 这还不存在。如果有人想变得富有,那么可以考虑这个想法。 编者注:目前已经有人正在实现这个想法,Byte Alliance 计划将WebAssembly 带到浏览器之外,Second State 已经发布了为服务端设计的WebAssembly 引擎开发者预览版。 不是云计算 WebAssembly 足以取代 PC 上本地安装的大多数应用程序。我们已经使用 WebGL(又名OpenGL ES 2.0)移植了游戏。我预测不久之后,受益于WebAssembly,像 LibreOffice 这样的大型应用可以直接从网站上获得,而无需安装。 在这种情况下,在本地安装应用没什么意义。本地安装的应用和 WebAssembly 应用之间几乎没有区别。WebAssembly 应用已经可以使用屏幕,键盘和鼠标进行交互。它可以在 2D 或 OpenGL 中进行图形处理,并使用硬件对视频流进行解码。可以播放和录制声音。可以访问网络摄像头。可以使用 WebSockets。可以使用 IndexedDB 存储大量数据在本地磁盘上。这些已经是 Web 浏览器中的标准功能,并且都可以使用 JavaScript 向 WebAssembly 暴露。 目前唯一困难的地方是 WebAssembly 无法访问本地文件系统。好吧,可以通过 HTML 使用文件上传对话,但这不算。最终,总会有人为此创建 API,并可能称之为 “WASI”。 “从互联网上运行应用程序!?胡说八道!“,你说。好吧,这是使用 Qt 和 WebAssembly 实现的文本编辑器 (以及更多)。 这是一个简单的例子。复杂的例子是在 WebBrowser 中运行的 Adobe Premier Pro 或 Blender。或者考虑像 Steam 游戏一样可以直接从网络上运行。这听起来像小说,但从技术上说这并非不能发生。 它会来的。 让我们裸奔! 目前,WebAssembly 在包含 HTML 和 Javascript 包装器的环境中执行。为什么不脱掉这些?有了 WebAssembly,为什么还要在浏览器中包含 HTML 渲染器和 JavaScript 引擎? 通过为所有服务提供标准化 API,这些服务通常是 Web 浏览器提供的,可以创建裸 WebAssembly。就是没有 HTML和 Javascript 包装来管理的 WebAssembly。访问的网页是 .wasm 文件,浏览器会抓取并运行该文件。浏览器为WebAssembly 模块提供画布,事件处理程序以及对浏览器提供的所有服务的访问。 这目前还不存在。如果现在使用 Web 浏览器直接访问 .wasm 文件,它会询问是否要下载它。我假设将设计所需的 API 并使其工作。 结果是 Web 可以发展。网站不再局限于 HTML,CSS 和 Javascript。可以创建全新的文档描述语言。可以发明全新的布局引擎。而且,对于像我这样的 polyglots 最相关,我们可以选择任何编程语言来实现在线服务。 可访问性 但我听到了强烈抗议!可访问性怎么样??搜索引擎怎么办? 好吧,我还没有一个好的答案。但我可以想象几种技术解决方案。 一个解决方案是我们保留内容和表现的分离。内容以标准化格式编写,例如 HTML。演示文稿由 WebAssembly 应用管理,该应用可以获取并显示内容。这允许网页设计师使用想要的任何技术进行任意演示 - 不需要 CSS,而搜索引擎和需要不同类型的可访问性的用户仍然可以访问内容。 请记住,许多 WebAssembly 应用并不是可以通过文本访问的,例如游戏和许多应用。盲人不会从图像编辑器中获得太多好处。 另一个解决方案是发明一个 API,它可以作为 WebAssembly 模块,来提供想在屏幕上呈现的 DOM,供屏幕阅读器或搜索引擎使用。基本上会有两种表示形式:一种是在图形画布上,另一种是产生结构化文本输出。 第三种解决方案是使用屏幕阅读器或搜索引擎可以使用的元数据来增强画布。执行 WebAssembly 并在画布上呈现内容,其中包含描述渲染内容的额外元数据。例如,该元数据将包括屏幕上的区域是否是菜单以及存在哪些选项,或者区域是否想要文本输入,以及屏幕上的区域的自然排序(也称为标签顺序)是什么。基本上,曾经在 HTML 中描述的内容现在被描述为具有元数据的画布区域。同样,这只是一个想法,它可能在实践中很糟糕。 可能是什么 1995年,Sun Microsystems 发布了 Java,带有 Java applets 和大量的宣传。有史以来第一次,网页可以做一些比 和 GIF 动画更有趣的事情。开发人员可以使应用完全在用户的 Web 浏览器中运行。它们没有集成到浏览器中,而是实现为繁重的插件,需要安装整个 JVM。1995年,这不是一个小的安装。applets 也需要一段时间来加载并使用大量内存。我们现在凭借大量内存,这不再是一个问题,但在 Java 生命的第一个十年里,它让体验变得令人厌烦。 applets 也不可靠。无法保证它们会运行,尤其是在用户使用 Microsoft 的实现时。他们也不安全,这是棺材里的最后一颗钉子。 以 JVM 为荣,其他语言最终演变为在 JVM 上运行。但现在,那艘船航行了。 FutureSplash / Macromedia / Adobe Flash 也是一个竞争者,但是是专有的,具有专有工具集和专有语言的专有格式。我读到他们确实在2009年开启了文件格式。最终从浏览器中删除了支持,因为它存在安全风险。 这里的结论是,如果希望您的技术存在于每个人的机器上,那么安全性就需要正视。我真诚地希望 WebAssembly 作为标准对安全问题做出很好的反应。 需要什么? WebAssembly 仍处于初期阶段。它目前能很好的运行代码,而规范版本是 1.0,二进制格式定型。目前正在开展SIMD 指令支持。通过 Web Workers 进行多线程处理也正在进行中。 工具可用,并将在未来几年不断改进。浏览器已经让你窥视 WebAssembly 文件。至少 Firefox 允许查看WebAssembly 字节码,设置断点并查看调用堆栈。我听说浏览器也有 profiling 支持。 语言支持包括一套不错的语言集合–C,C++和Rust是一流的公民。C#,Go和Lua显然有稳定的支持。Python,Scala,Ruby,Java和Typescript都有实验性支持。这可能是一个傲慢的陈述,但我真的相信任何想要在21世纪存在的语言都需要能够在 WebAssembly 上编译或运行。 在访问外部设备的 API 支持方面,我所知道的唯一可用于裸 WebAssembly 的 API 是 WASI,它允许文件和流访问等核心功能,允许 WebAssembly 在浏览器外运行。否则,任何访问外部世界的 API 都需要在浏览器中的 Javascript 中实现。除了本地机器上的文件访问,打印机访问和其他新颖的硬件访问(例如非标准蓝牙或USB设备)之外,应用所需的一切几乎都可以满足。“裸WebAssembly”并不是它成功的必要条件; 它只是一个小的优化,不需要浏览器包含对 HTML,CSS 或 Javascript 的支持。 我不确定在桌面环境中让 WebAssembly 成为一等公民需要什么。需要良好的复制和粘贴支持,拖放支持,本地化和国际化,窗口管理事件以及创建通知的功能。也许这些已经可以从网络浏览器中获得; 我经常惊讶与已经可能的事情。 引发爆炸的火花是创建允许现有应用移植的环境。如果创造了“用于 WebAssembly 的 Linux 子系统”,那么可以将大量现有的开源软件移植到 WebAssembly 上。它需要模拟一个文件系统 - 可以通过将文件系统的所有只读部分都缓存为 HTTP 请求来完成,并且所有可写部分都可以在内存中,远程存储或使用浏览器可以提供的任何文件访问。图形支持可以通过移植 X11 或 Wayland 的实现来使用 WebGL(我理解已经作为 AIGLX 存在?)。 一些 SDL 游戏已经被移植到 WebAssembly - 最着名的是官方演示。 一旦 JVM 在 WebAssembly 中运行,就可以在浏览器中运行大量的 Java 软件。同样适用于其他虚拟机和使用它们的语言。 与 Windows 软件的巨大世界一样,我没有答案。WINE 和 ReactOS 都需要底层的 x86 或 x86-64 机器,所以唯一的选择是获取源代码并移植它,或者使用 x86 模拟器。 尾声 WebAssembly 即将到来。 它来得很慢,但现在所有的部分都可以在你正在使用的浏览器上使用。现在我们等待构建用于从各种编程语言中定位 WebAssembly 的基础设施。一旦构建完成,我们将摆脱 HTML,CSS 和 Javascript 的束缚。 加入阿里云钉钉群享福利:每周技术直播,定期群内有奖活动、大咖问答 阿里云开发者社区

茶什i 2020-01-07 10:32:35 0 浏览量 回答数 0

问题

买阿里云是用来做什么?难道会让摸不着头脑的配置环境拦着你/?

dieshang668 2019-12-01 21:36:03 12350 浏览量 回答数 10

问题

Go语言编程有哪些利与弊?编程时如何判断是否应该用Go?

有只黑白猫 2020-01-06 13:37:29 15 浏览量 回答数 1

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

软件性能测试的本质

技术小菜鸟 2019-12-01 21:45:03 4548 浏览量 回答数 1

回答

Java之JVM垃圾回收 内存结构以及垃圾回收算法前言:由于小组技术分享的需要,懂的不是很多所以我就找了这个我自己感兴趣的知识点给大家做个简单的介绍。由于是新人,算不了很懂,只是总结性的讲了些概念性的东西。给大家分享的同时,算是给自己做个笔记吧。作为Java语言的核心之一,JVM垃圾回收帮我们解决了让我们很头疼的垃圾回收问题。我们不需要像VC++一样,作为内存管理的统治者需要我们对我们分配的每一块内存进行回收,否则就会造成内存泄露问题。是不是只要有JVM存在我们就不会出现内存泄露问题,出现内存泄露问题我们又该怎么办,如果我们想提高我们程序的稳定性和其他性能我们能从什么地方下手!!!相信这些问题是我们程序过程中不可逾越的。了解JVM的内存分配及其相应的垃圾回收机制,不仅仅是可以了解底层的JVM运行机制,而且对于程序性能的优化和提升还是很有必要的。一、JVM内存分配区域结构图一从图一可以看出JVM中的内存分配包括PC Register(PC寄存器) JVM栈 堆(Heap) 方法区域(MethodArea)运行时常量池(RuntimeConstant Pool) 本地方法堆栈(NativeMethod Stacks),这几部分区域但是从程序员的角度来看我们只关注JVM Heap和JVM Stack,因为这两部分是直接关系程序运行期间的内存状态,所以我会主要介绍这两部分内存,其他的我只是给出了简单的一些概念性解释:PC Register(Program Counter 寄存器):主要作用是记录当前线程所执行的字节码的行号。方法区域(MethodArea):方法区域存放了所加载的类的信息(名称、修饰符等)、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息,法区域也是全局共享的,它在虚拟机启动时在一定的条件下它也会被GC,当方法区域需要使用的内存超过其允许的大小时,会抛出OutOfMemory的错误信息。运行时常量池(RuntimeConstant Pool):存放的为类中的固定的常量信息、方法和Field的引用信息等,其空间从方法区域中分配。本地方法堆栈(NativeMethod Stacks):JVM采用本地方法堆栈来支持native方法的执行,此区域用于存储每个native方法调用的状态。JVM栈:主要存放一些基本类型的变量和对象的引用变量。JVM堆:用来存放由 new 创建的对象和数组Java 虚拟机的自动垃圾回收器来管理(注意数组也是对象,所以说数组也是存放在JVM堆中)。由于栈中存放的是主要存放一些基本类型的变量和对象的引用变量,所以当过了变量的作用区域或者是当程序运行结束后它所占用的内存会自动的释放掉,所以不用来关心,下面我们主要来说的是堆内存的分配以及回收的算法。二、JVM堆内存介绍工欲善其事,必先利其器。所以了解堆内存的内部结构是很必要的。在Jvm中堆空间划分为三个代:年轻代(Young Generation)、年老代(Old Generation)和永久代(Permanent Generation)。年轻带主要是动态的存储,年轻带主要储存新产生的对象,年老代储存年龄大些的对象,永久带主要是存储的是java的类信息,包括解析得到的方法、属性、字段等。永久带基本不参与垃圾回收。所以说我们说的垃圾回收主要是针对年轻代和年老代。图二年轻代又分成3个部分,一个eden区和两个相同的survior区。刚开始创建的对象都是放置在eden区的。分成这样3个部分,主要是为了生命周期短的对象尽量留在年轻带。当eden区申请不到空间的时候,进行minorGC,把存活的对象拷贝到survior。年老代主要存放生命周期比较长的对象,比如缓存对象。(经过IBM的一个研究机构研究数据表明,基本上80%-98%的对象都会在年轻代的Eden区死掉从而本回收掉,所以说真正进入到老年代的对象很少,这也是为什么MinorGC比MajorGC更加频繁的原因)具体JVM内存垃圾回收过程描述如下 :1、对象在Eden区完成内存分配2、当Eden区满了,再创建对象,会因为申请不到空间,触发minorGC,进行young(eden+1survivor)区的垃圾回收3、minorGC时,Eden不能被回收的对象被放入到空的survivor(Eden肯定会被清空),另一个survivor里不能被GC回收的对象也会被放入这个survivor,始终保证一个survivor是空的4、当做第3步的时候,如果发现survivor满了,则这些对象被copy到old区,或者survivor并没有满,但是有些对象已经足够Old,也被放入Old区 XX:MaxTenuringThreshold5、当Old区被放满的之后,进行fullGC补充: MinorGC:年轻代所进行的垃圾回收,非常频繁,一般回收速度也比较快。 MajorGC:老年代进行的垃圾回收,发生一次MajorGC至少伴随一次MinorGC,一般比MinorGC速度慢十倍以上。 FullGC:整个堆内存进行的垃圾回收,很多时候是MajorGC 以后就是堆内存结构已经大致的垃圾回收过程。三、对象分配原则1.对象优先分配在Eden区,如果Eden区没有足够的空间时,虚拟机执行一次Minor GC。2.大对象直接进入老年代(大对象是指需要大量连续内存空间的对象)。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝(新生代采用复制算法收集内存)。3.长期存活的对象进入老年代。虚拟机为每个对象定义了一个年龄计数器,如果对象经过了1次Minor GC那么对象会进入Survivor区,之后每经过一次Minor GC那么对象的年龄加1,知道达到阀值对象进入老年区。4.动态判断对象的年龄。如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象可以直接进入老年代。5.空间分配担保。每次进行Minor GC时,JVM会计算Survivor区移至老年区的对象的平均大小,如果这个值大于老年区的剩余值大小则进行一次Full GC,如果小于检查HandlePromotionFailure设置,如果true则只进行Monitor GC,如果false则进行Full GC。四、垃圾收集器作为JVM中的核心之一垃圾收集器,主要完成的功能包括:(1)发现无用信息对象;(2)回收被无用对象占用的内存空间,使该空间可被程序再次使用。所以说我们在实现垃圾收集器的同时就要实现两个算法一个是发现无用的对象第二就是回收该对象的内存。收集器主要分为引用计数器和跟踪收集器两种,Sun JDK中采用跟踪收集器作为GC实现策略。发现无用对象只要的实现算法包括引用计数法和根搜索算法,引用计数法主要是JVM的早期实现方法,因为引用计数无法解决循环引用的问题,所以现在JVM实现的主要是根搜索算法,引用计数法:堆中的每个对象对应一个引用计数器。当每一次创建一个对象并赋给一个变量时,引用计数器置为1。当对象被赋给任意变量时,引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用),引用计数器减1,一旦引用计数器为0,对象就不可用从而可以被回收。 根搜索算法:通过一系列的名为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连(用图论的话来说就是从GC Roots到这个对象不可达)时,则证明此对象是不可用的。目前的收集器主要有三种:串行收集器:使用单线程处理所有垃圾回收工作,因为无需多线程交互,所以效率比较高并行收集器:对年轻代进行并行垃圾回收,因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用并发收集器:可以保证大部分工作都并发进行(应用不停止),垃圾回收只暂停很少的时间,此收集器适合对响应时间要求比较高的中、大规模应用五、垃圾收集器的回收算法Copying算法:算法:复制采用的方式为从根集合扫描出存活的对象,并将找到的存活对象复制到一块新的完全未使用的空间中。 过程: 此算法把内存空间划为两个相等的区域,每次只使用其中一个区域。垃圾回收时,遍历当前使用区域,把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象,因此复制成本比较小,同时复制过去以后还能进行相应的内存整理,不过出现“碎片”问题。当然,此算法的缺点也是很明显的,就是需要两倍内存空间。Mark-Sweep算法: 算法:标记-清除采用的方式为从根集合开始扫描,对存活的对象进行标记,标记完毕后,再扫描整个空间中未标记的对象,并进行回收。 过程: 第一阶段从引用根节点开始标记所有被引用的对象,第二阶段遍历整个堆,把未标记的对象清除。它停止所有工作,收集器从根开始访问每一个活跃的节点,标记它所访问的每一个节点。走过所有引用后,收集就完成了,然后就对堆进行清除(即对堆中的每一个对象进行检查),所有没有标记的对象都作为垃圾回收并返回空闲列表。Mark-Compact算法: 算法:标记阶段与“Mark-Sweep”算法相同,但在清除阶段有所不同。在回收不存活对象所占用的内存空间后,会将其他所有存活对象都往左端空闲的空间进行移动,并更新引用其对象指针。过程:此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段,第一阶段从根节点开始标记所有被引用对象,第二阶段遍历整个堆,把清除未标记对象并且把存活对象“压缩”到堆的其中一块,按顺序排放。此算法避免了“标记-清除”的碎片问题,同时也避免了“复制”算法的空间问题。Sun JDK GC策略:新生代算法实现:Copying,Copying,Copying旧生代算发实现:Mark-Sweep-Compact,Mark –Compact,Mark –Sweep!!六、JvisuaVM 工具如果我们想优化自己的程序,那么我们就必须清楚的了解不同代码程序所消耗的性能多少,作为JDK的一部分,这个工具给我们提供了很大的帮助。这个工具可以在JDK的bin目录下找到,功能很强大,可以注意利用

auto_answer 2019-12-02 01:56:35 0 浏览量 回答数 0

问题

搜索引擎背后的经典数据结构和算法 6月10日 【今日算法】

游客ih62co2qqq5ww 2020-06-15 07:32:11 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站