• 关于

    递归类型问题怎么解决

    的搜索结果

问题

Vue面试题汇总【精品问答】

问问小秘 2020-05-25 18:02:28 11132 浏览量 回答数 2

问题

程序员报错行为大赏-配置报错

问问小秘 2020-06-11 13:18:25 6 浏览量 回答数 1

问题

【精品问答】python技术1000问(1)

问问小秘 2019-12-01 21:57:48 454222 浏览量 回答数 19

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

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

问题

【Java学习全家桶】1460道Java热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:15 27612 浏览量 回答数 19

问题

dubbo 支持的通信协议?有哪些序列化协议?说下 Hessian 的数据结构?【Java问答】48

剑曼红尘 2020-07-01 15:18:43 7 浏览量 回答数 1

问题

一个函数秒杀 2Sum 3Sum 4Sum 问题 7月9日 【今日算法】

游客ih62co2qqq5ww 2020-07-10 07:34:19 5 浏览量 回答数 1

问题

2018python技术问答集锦,希望能给喜欢python的同学一些帮助

技术小能手 2019-12-01 19:31:10 2040 浏览量 回答数 2

问题

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

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

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

回答

看了下 servo 中 dom 节点的处理方式,构造了个例子 use std::cell::{Cell, RefCell}; struct Element { flag: Cell<i32>, id: Cell<i32>, children: RefCell<Vec<RefCell<Element>>>, } impl Element { fn new() -> Element { Element { flag: Cell::new(0), id: Cell::new(1), children: RefCell::new(Vec::new()), } } fn add_child(&self, child: Element) { self.flag.set(self.flag.get() + 1); self.children.borrow_mut().push(RefCell::new(child)); } fn before_remove(&self) { self.flag.set(0); } fn after_remove(&self) { self.id.set(0); } fn remove_children(&self) { self.before_remove(); for e in self.children.borrow().iter() { e.borrow().remove_children(); } self.after_remove(); } } fn main() { let e1 = Element::new(); let e2 = Element::new(); let e3 = Element::new(); let e4 = Element::new(); let e5 = Element::new(); let e6 = Element::new(); let e7 = Element::new(); e6.add_child(e7); e5.add_child(e6); e4.add_child(e5); e3.add_child(e4); e2.add_child(e3); e1.add_child(e2); e1.remove_children(); println!("..."); } Element 中所有的字段用 Cell/RefCell 包装后,所有的成员方法都使用 &self 不可变借用来调用 remove_children 应该是能还原你原始的问题了。所有要嵌套/递归修改自己的地方都只用 borrow() 不可变借用就行。 而其他的基础类型字段,如 i32, vec 由于不会嵌套修改,可以 borrow_mut() 修改完马上还回来,保证一句话修改完就行。 children 我给简写了,实际上由于要再被其他人引用,应该在外面再包一层 Rc 的。 大致搜了下有类似需求的一些项目,处理方式都是类似这样的。 ######回复 @DogFeet :c++里,这些地方相对较少,而变更对象时,改其它对象是很多的,在有交互的代码里可以说是大量,成本不一样######回复 @templar : 不需要把每个修改都封装到单独的函数里面。至于说所有路径都测试到,C++也一样有这个问题,如果你在 Objects 的迭代中某个 object.update 中修改了 Objects 的布局,一样可能会导致迭代器出问题,这些只是你在 C++ 中习惯了,知道 update 中有些事情其实也是不能做的。######回复 @DogFeet : borrow_mut在运行中检查,实际中很难所有路径都测试到,所以rust还是太累了,暂时还是不用了,不过这个问题也算是有解决方法了,谢谢了######回复 @DogFeet : 那得很注意,把每个修改都封到单独的函数里,行是行,就是太费劲了~~~######回复 @templar : 转换成你那个例子就是 update 用 &self 调用,只需要 borrow 借用,update 中又一次借用自己也是用 borrow,由于 life 字段被 Cell 包起来了,所以可以通过 &self 修改。而多次 borrow 并不会有什么问题。这样就解决你原来的问题了。###### 已经用上rust了!  赞一个, ######用Recell+Mutex试下。###### 如果是多个线程要修改你的objects,则用Arc 如果只有一个线程多个地方要修改objects,则用Rc ######回复 @DogFeet : 搞不定~~求个示例代码。。。这个问题就是持有一个μt T的情况下,调用其成员函数,在该成员函数里,又需要修改自已或别的对象,就是也要获得μt T,在游戏服务器里,放技能这类逻辑,都会修改多个对象的属性###### @templar .而且用Rc了一般就不会再传引用了,你什么时候见过到处 &shared_ptr的。。。。。全局变量的问题,Rust是不推荐的,所以你要写传统语言中常见的单例模式会发现很难。###### @templar Rc没有你说的这种要求,都说了就是非线程安全版的shared_ptr######回复 @DogFeet : 看文档,rc是用于不可变量的,要获得μt还是得传入μt RC<T>,一层层往上推,又得全是μt,而且还要求rc是unique的,可能你说的可行吧,但现在暂时没什么兴趣了,写一个全局变量都这么费劲,哪天有精神了再弄吧,多谢回答######回复 @templar : Rc 就是用来解决你多个地方要共享修改一个元素的,等同于 C++ 非线程安全版 shared_ptr###### 引用来自“DogFeet”的评论 如果是多个线程要修改你的objects,则用Arc 如果只有一个线程多个地方要修改objects,则用Rc  #[derive(Debug)] pub struct OBJ {     x : i32, } fn main() {     let mut x1 = Rc::new(OBJ { x: 100 } );     let mut x2 = x1.clone();     x1.x = 101;     x2.x = 102;     println!("{:?}",x1);     println!("{:?}",x2); } src\main.rs(105,5): error : cannot assign to immutable field src\main.rs(106,5): error : cannot assign to immutable field std::rc::Rc A reference-counted pointer type over an immutable value. 要获得&mut T,还是需要 fn get_mut(rc: &mut Rc<T>) -> Option<&mut T>[−] Unstable Returns a mutable reference to the contained value if the Rc<T> is unique. Returns None if the Rc<T> is not unique. ###### 我想可能rust不适合其它语言那种N层嵌套调用,可能得写成比较扁平的类,Github上的开源,也大都如此,比如技能这个,可能就得把技能拉出来,跟OBJ同层,用RefCell只临时borrow_mut,不过这样又得导致很多其它的不便,也是挺恶心的 ###### fn main() { let x1 = Rc::new(RefCell::new(OBJ { x: 100 } )); let x2 = x1.clone(); x1.borrow_mut().x = 101; x2.borrow_mut().x = 103; println!("{:?}",x1); println!("{:?}",x2); } 所有使用你那个HashMap的地方拿到的都是一个类似上面的 x1, x2 的对象,不用保存引用,可变引用的哦,也不会传染到上层哦。 我比较好奇的是你的 get_global_objects () 打算怎么实现,要实现这种类似单例类会很麻烦的。 ######https://github.com/Kimundi/lazy-static.rs 这个宏可以简化全局变量######Global是有办法的,参照os.Stdout,比较烦一点,不过可以用宏实现######两次borrow_mut会panic的,在N层嵌套里,要想保持单一个borrow几乎不可能的,一个技能出发一个效果,影响N个对象,N个对象上的反应器又会触发其它效果,完全不可控,这个我在最上面说过不行######我说的两次borrow_mut会panic的,是指先持一个mut,调用其内部函数,在函数里,可能需要borrow自已,或其它对象,一层层函数调下去,需要borrow的对象是动态的,不可知的 你没仔细看我的问题 impl for OBJ { fn update(&mut self) { // 这里borrow另一个,可能是自已,或别人 // 假如那个对象已经被borrow了,就panic了 } } fn main() {     let x1 = Rc::new(RefCell::new(OBJ { x: 100 } ));     let x2 = x1.clone();       x1.borrow_mut().update()       println!("{:?}",x1);     println!("{:?}",x2); } ######不过RefCell可以解决HashMap的引用了,不必都用iter_mut了###### 引用来自“templar”的评论 我想可能rust不适合其它语言那种N层嵌套调用,可能得写成比较扁平的类,Github上的开源,也大都如此,比如技能这个,可能就得把技能拉出来,跟OBJ同层,用RefCell只临时borrow_mut,不过这样又得导致很多其它的不便,也是挺恶心的 如果你能做到扁平的,那就可以直接用 &, &mut 来borrow了,用完直接还掉,就没上面的问题了呀。 但事实上很难做到的,我也是做游戏的。比如常见的触发器需求,有时候触发器关联了2个对象,这个触发器需要引用这2个对象吧,C++可能就直接用到智能指针了(有的解决方案是用ID做句柄,不过也有麻烦的地方,要手动解除ID的关联,除非能保证ID不回环)。 所有的对象都被 Objects borrow 了,触发器再 borrow 肯定要出事,这种需求很难通过做平来避免的。######打包成事件扔到顶层循环处理,会勉强可以,不过很不自然,会导致别的问题###### 引用来自“templar”的评论我说的两次borrow_mut会panic的,是指先持一个mut,调用其内部函数,在函数里,可能需要borrow自已,或其它对象,一层层函数调下去,需要borrow的对象是动态的,不可知的 你没仔细看我的问题 impl for OBJ { fn update(&mut self) { // 这里borrow另一个,可能是自已,或别人 // 假如那个对象已经被borrow了,就panic了 } } fn main() {     let x1 = Rc::new(RefCell::new(OBJ { x: 100 } ));     let x2 = x1.clone();       x1.borrow_mut().update()       println!("{:?}",x1);     println!("{:?}",x2); } 你说的这个我还没考虑到。 如果是这样,那确实很麻烦,按照多人共享用 Rc 的策略,如果 Objects 中的 entry 也需要多人共享,那把 entry 也用 Rc 包起来?不过这样,entry.update(&mut self) 就得改写成 entry_update(e: Rc<...>) 了,这样也确实很丑。 或者是模仿 Rc, Arc 这种用 unsafe 包装内部可变性的方式,把 entry 的 update 用 unsafe 包起来,外面拿 immutable borrow 的 entry 也能通过调用其成员函数来做到修改内部状态。就像 Rc 的 clone。不过这种感觉也不是解决方法。 我再问问其他看看 ######unsafe也试过了,在unsafe里不能把获得的μt T作为参数调用其它安全函数

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

回答

曾经因为看不懂数据结构和算法,而一度怀疑是自己太笨,实际上,很多人在第一次接触这门课时,都会有这种感觉,觉得数据结构和算法很抽象,晦涩难懂,宛如天书。正是这个原因,让很多初学者对这门课望而却步,希望以下分享能为初学者排忧解难。 我个人觉得,其实真正的原因是你没有找到好的学习方法,没有抓住学习的重点。实际上,数据结构和算法的东西并不多,常用的、基础的知识点更是屈指可数。只要掌握了正确的学习方法,学起来并没有看上去那么难,更不需要什么高智商、厚底子。 还记得大学里每次考前老师都要划重点吗?今天,我就给你划划我们这门课的重点,再告诉你一些我总结的学习小窍门。相信有了这些之后,你学起来就会有的放矢、事半功倍了。 什么是数据结构?什么是算法? 大部分数据结构和算法教材,在开篇都会给这两个概念下一个明确的定义。但是,这些定义都很抽象,对理解这两个概念并没有实质性的帮助,反倒会让你陷入死抠定义的误区。毕竟,我们现在学习,并不是为了考试,所以,概念背得再牢,不会用也就没什么用。 虽然我们说没必要深挖严格的定义,但是这并不等于不需要理解概念。下面我就从广义和狭义两个层面,来帮你理解数据结构与算法这两个概念。 从广义上讲,数据结构就是指一组数据的存储结构。算法就是操作数据的一组方法。 图书馆储藏书籍你肯定见过吧?为了方便查找,图书管理员一般会将书籍分门别类进行“存储”。按照一定规律编号,就是书籍这种“数据”的存储结构。 那我们如何来查找一本书呢?有很多种办法,你当然可以一本一本地找,也可以先根据书籍类别的编号,是人文,还是科学、计算机,来定位书架,然后再依次查找。笼统地说,这些查找方法都是算法。 从狭义上讲,是指某些著名的数据结构和算法,比如队列、栈、堆、二分查找、动态规划等。这些都是前人智慧的结晶,我们可以直接拿来用。我们要讲的这些经典数据结构和算法,都是前人从很多实际操作场景中抽象出来的,经过非常多的求证和检验,可以高效地帮助我们解决很多实际的开发问题。 那数据结构和算法有什么关系呢?为什么大部分书都把这两个东西放到一块儿来讲呢? 这是因为,数据结构和算法是相辅相成的。数据结构是为算法服务的,算法要作用在特定的数据结构之上。因此,我们无法孤立数据结构来讲算法,也无法孤立算法来讲数据结构。 比如,因为数组具有随机访问的特点,常用的二分查找算法需要用数组来存储数据。但如果我们选择链表这种数据结构,二分查找算法就无法工作了,因为链表并不支持随机访问。 数据结构是静态的,它只是组织数据的一种方式。如果不在它的基础上操作、构建算法,孤立存在的数据结构就是没用的。 现在你对数据结构与算法是不是有了比较清晰的理解了呢?有了这些储备,下面我们来看看,究竟该怎么学数据结构与算法。 看到数据结构和算法里的“算法”两个字,很多人就会联想到“数学”,觉得算法会涉及到很多深奥的数学知识。那我数学基础不是很好,学起来会不会很吃力啊? 数据结构和算法课程确实会涉及一些数学方面的推理、证明,尤其是在分析某个算法的时间、空间复杂度的时候,但是这个你完全不需要担心。 学习的重点在什么地方? 提到数据结构和算法,很多人就很头疼,因为这里面的内容实在是太多了。这里,我就帮你梳理一下,应该先学什么,后学什么。你可以对照看看,你属于哪个阶段,然后有针对地进行学习。 想要学习数据结构与算法,首先要掌握一个数据结构与算法中最重要的概念——复杂度分析。 这个概念究竟有多重要呢?可以这么说,它几乎占了数据结构和算法这门课的半壁江山,是数据结构和算法学习的精髓。 数据结构和算法解决的是如何更省、更快地存储和处理数据的问题,因此,我们就需要一个考量效率和资源消耗的方法,这就是复杂度分析方法。所以,如果你只掌握了数据结构和算法的特点、用法,但是没有学会复杂度分析,那就相当于只知道操作口诀,而没掌握心法。只有把心法了然于胸,才能做到无招胜有招! 所以,复杂度分析这个内容,你也一定要花大力气来啃,必须要拿下,并且要搞得非常熟练。否则,后面的数据结构和算法也很难学好。 搞定复杂度分析,下面就要进入数据结构与算法的正文内容了。 为了让你对数据结构和算法能有个全面的认识,我画了一张图,里面几乎涵盖了所有数据结构和算法书籍中都会讲到的知识点。 但是,作为初学者,或者一个非算法工程师来说,你并不需要掌握图里面的所有知识点。很多高级的数据结构与算法,比如二分图、最大流等,这些在我们平常的开发中很少会用到。所以,你暂时可以不用看。我还是那句话,咱们学习要学会找重点。如果不分重点地学习,眉毛胡子一把抓,学起来肯定会比较吃力。 所以,结合我自己的学习心得,还有这些年的面试、开发经验,我总结了20个最常用的、最基础数据结构与算法,不管是应付面试还是工作需要,只要集中精力逐一攻克这20个知识点就足够了。 这里面有10个数据结构:数组、链表、栈、队列、散列表、二叉树、堆、跳表、图、Trie树;10个算法:递归、排序、二分查找、搜索、哈希算法、贪心算法、分治算法、回溯算法、动态规划、字符串匹配算法。 掌握了这些基础的数据结构和算法,再学更加复杂的数据结构和算法,就会非常容易、非常快。 与此同时,为了帮助大家学习算法,准备了一份学习资料,获取方式:关注我的公众号“程序媛不是程序猿”,回复“算法”即可弹出领取地址。对于新手来说很适用。 在学习数据结构和算法的过程中,你也要注意,不要只是死记硬背,不要为了学习而学习,而是要学习它的“来历”“自身的特点”“适合解决的问题”以及“实际的应用场景”。对于每一种数据结构或算法,我都会从这几个方面进行详细讲解。只要你掌握了《数据结构与算法之美》每节课里讲的内容,就能在开发中灵活应用。 学习数据结构和算法的过程,是非常好的思维训练的过程,所以,千万不要被动地记忆,要多辩证地思考,多问为什么。如果你一直这么坚持做,你会发现,等你学完之后,写代码的时候就会不由自主地考虑到很多性能方面的事情,时间复杂度、空间复杂度非常高的垃圾代码出现的次数就会越来越少。你的编程内功就真正得到了修炼。 一些可以让你事半功倍的学习技巧 前面我给你划了学习的重点,作为一个过来人,现在我就给你分享一下,学习的一些技巧。掌握了这些技巧,可以让你化被动为主动,学起来更加轻松,更加有动力! 边学边练,适度刷题 “边学边练”这一招非常有用。建议你每周花1~2个小时的时间,集中把这周的三节内容涉及的数据结构和算法,全都自己写出来,用代码实现一遍。这样一定会比单纯地看或者听的效果要好很多! 有面试需求的同学,可能会问了,那我还要不要去刷题呢? 我个人的观点是可以“适度”刷题,但一定不要浪费太多时间在刷题上。我们学习的目的还是掌握,然后应用。除非你要面试Google、Facebook这样的公司,它们的算法题目非常非常难,必须大量刷题,才能在短期内提升应试正确率。如果是应对国内公司的技术面试,即便是BAT这样的公司,你只要彻底掌握这个专栏的内容,就足以应对。 多问、多思考、多互动 学习最好的方法是,找到几个人一起学习,一块儿讨论切磋,有问题及时寻求老师答疑。但是,离开大学之后,既没有同学也没有老师,这个条件就比较难具备了。 打怪升级学习法 学习的过程中,我们碰到最大的问题就是,坚持不下来。是的,很多基础课程学起来都非常枯燥。为此,我自己总结了一套“打怪升级学习法”。 游戏你肯定玩过吧?为什么很多看起来非常简单又没有乐趣的游戏,你会玩得不亦乐乎呢?这是因为,当你努力打到一定级别之后,每天看着自己的经验值、战斗力在慢慢提高,那种每天都在一点一点成长的成就感就不由自主地产生了。 知识需要沉淀,不要想试图一下子掌握所有 在学习的过程中,一定会碰到“拦路虎”。如果哪个知识点没有怎么学懂,不要着急,这是正常的。因为,想听一遍、看一遍就把所有知识掌握,这肯定是不可能的。学习知识的过程是反复迭代、不断沉淀的过程。 这些内容是我根据平时的学习和工作、面试经验积累,精心筛选出来的。只要掌握这些内容,应付日常的面试、工作,基本不会有问题。 以上内容出自近70000+程序员的算法课堂《数据结构与算法之美》,这个专栏是市面上唯一一门真正适用于工程师的专栏,专栏中列举大量实际软件开发中的场景,给你展示如何利用数据结构和算法解决真实的问题。整个专栏会涵盖100 多个算法真实项目场景案例,更难得的是它跟市面上晦涩的算法书籍不同的是,还手绘了一些清晰易懂的详解图(总共有 300 多张)。 手绘图—出自《数据结构与算法之美》 专栏已经更新完毕,72 篇文章,27 万字,这个专栏作者并非只是单纯地把某个知识点讲清楚,而是结合作者的理解、实践和经验来讲解,我相信它是一个跟所有国内、国外经典书籍都不一样的专栏,一个可以长期影响一些人的专栏。 这个专栏不会像《算法导论》那样,里面有非常复杂的数学证明和推理。作者会由浅入深,从概念到应用,一点一点给你解释清楚。你只要有高中数学水平,就完全可以学习。 当然,当然希望你最好有些编程基础,如果有项目经验就更好了。这样给你讲数据结构和算法如何提高效率、如何节省存储空间,你就会有很直观的感受。因为,对于每个概念和实现过程,作者都会从实际场景出发,不仅教你“是什么”,还会教你“为什么”,并且告诉你遇到同类型问题应该“怎么做”。 强烈推荐这个专栏给想攻克算法的同学,它改变了无数对算法恐惧的同学,我整理了一些专栏的评价给大家参考。

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