线程同步和线程异步的区别_java线程同步方法

怎么提高自己的系统设计和架构理论水平？ 　　记得当年架构师叫系统分析员。在国内对架构师、项目经理或者是技术总监这类的职责定位并不是很清晰。架构师这个话题很大，《软件架构设计》（程序员向架构师转型必备书籍）整体框架为大家整理出来了，下图：

原图无logo，手机方法为高清接下来要写的内容，全部是干货并且可以直接落地执行的。内容较长，希望大家耐心往下看。欢迎初中级程序员，一起努力。也欢迎架构大佬来补充~ 　　一、项目中的角色 　　客户：为系统开发买单的人，系统的业务价值用户：使用系统应用的人，功能需求，提升效率和易用性体验感等等项目经理：负责项目管理、组织、协调和沟通等管理工作需求分析师（产品经理或技术leader）：比如业务分析，需求，需求调研，需求管理，写需求规格等等系统架构师：系统分析，架构规划，技术选型，核心功能需求和非功能性需求的架构设计系统设计师：架构的基础上，核心功能和非核心功能的详细设计开发人员：根据架构设计和详设计完整编码和单测试，达到提测标准测试人员：验证开发功能是否满足需求，包括了功能、性能，集成，压力，安全，回归等测试运维人员：负责部署环境的搭建和维护。 　　这个是一个项目当中正常的各个岗位的职责，但是目前看到中小型公司的项目经理就是系统架构师也是系统设计师，甚至一些小公司的团队老板是直接领导人，只有领导和开发。 　　二、架构师的主要职责和工作内容 　　架构师在项目中是承上启下的作用，实际工作是参与到了系统建设的全过程。 　　目前架构师的职责是： 　　支持售前的需求阶段，提供概念架构和技术咨询首先是分析，然后是设计架构，技术选型，给出架构解决方案指导整个团队成员，按照架构设计完成开发的全流程（开发测试发布运维）开发或者设计开发框架，要指定代码的规范程度，设计机构原型，验证架构与耐性组织技术或者架构培训，把我整体开发和架构的方向要平衡成本，与团队沟通，技术风险管理 　　按照项目的阶段需要完成下面工作： 　　售前需要给到商务支持，提供解决方案需求阶段，与产品经理进行需求分析，参与沟通，完成需求模型（说白了就是动业务）架构阶段：进行系统分析和设计，进行系统抽象，设计系统模型进行技术原型，开发架构原型设计阶段：要知道设计人员开发阶段：团队中遇到困难，架构师要知道解决方案测试阶段：也是提供指导，特别是在非功能测试发布阶段：指导按照架构进行部署其他工作：技术选型，定期人员培训，随时给出技术指导 　　我先把架构师得职责写在前面主要原因是，只有知道了工作职责才知道成长方向。一个完整得系统架构包括了：整体得技术架构，子系统得架构/模块/功能/详细设计，通信机制，事物机制，接口定义，领域模型，业务流程，数据库设计，中间件，组件架构，部署架构师等。 　　三、架构师成长路径 　　不管是任何行业的成长路径都是一条：吸收新知识，实践到工作中，定期总结，找到不足重复学习。 　　3.1 看代码累积经验 　　代码是最好的老师，有些程序员会说我不是天天写代码吗？大家要学会从代码中学习设计思想，方法是提升类库设计能力。需要来印证我们所学的概念和理论这就是架构师看代码的观点。 　　要随时带着问题看代码（比如看到热门开源的时候）：为什么要这么写代码？为什么要这样设计？哪里不足？我会怎么优化？ 　　一个类库有无数个方法，应该怎么看呢？（敲黑板！下面是重点了！可落地执行）设计模式：23种设计模式你了解多少？？不可能一下子就理解他们的用法，但是要记住是名字和基本的用途。语法规范：是否熟悉了自己语言的官方代码规范和命名规则要懂UML中对类的图形表示方法（类、接口、抽象、继承关系、使用关系） 　　其实代码本身是没有什么价值的，价值核心就在于设计，可以让我们深入的理解到代码是怎么进行实现的。 　　有效学习： 　　在排行榜上的那些语言都有官方提供的最佳实践，我们可以直接下载学习。这是一个程序员的必修课，如果你现阶段还没有这一步。那么可以开始了，同一个需求，我们可以用各种方法来设计但是什么最好？为什么最好？官方提供的「最佳实践」中会有很多文档辅助，我们长期积累这样的学习和阅读，就会get一个能力“随便哪一个Dll，你可以直接说出Dll的特点和功能”。 　　3.2 实践出真知 　　上面说的是看代码，我们长期在某一个领域内搬砖，时间久了就知道这个领域内的软件设计理念和实现。比如一个网站的开发我们可以用http://ASP.NET MCV还能用PHP或者各种语言实现，但是其中实现方法和代码量完全不同。 　　举个例子，我们开发一个博客：http://ASP.NET和Java的实现差不多，学习曲线都很长PHP相对就简单很多，成本约很低NodeJs性能是最高的，学习曲线最短，代码量也少 　　但是我们除了以上内容，还需要考虑的是部署环境。 　　3.3 有效写代码 　　大家可能有1-2门很熟悉的语言，但是作为架构师我们应该要求自己的代码：易读：所有命名都要规范，所有接口全部有注释易用：每一个类和方法，少参与，容易理解的设计框架化：一个一个类的写，整体效率下降，是否可以灵活运营模式在代码中同时构建多个类参考性：面对复杂场景需要多写实力，也是测试设计的易用性的方法 　　怎么可以达到上述的要求呢？除本职工作外你有否自己写代码？多写代码片，完整的记录自己的代码片，自己练习也要有清晰的注释可以通过开源项目去做一个仿造品尝试使用模式控制类的规划 　　3.4 基本理论和技能 　　面向对象设计的理论：所有的设计都是有理有据并非自己想出来的，切记不要拍脑门！ 　　设计模式：这真的是基本功了，设计模式用来解耦组件内对象之间的关系，会让我们后期开发阶段非常顺利。但是如果设计模式用不好，就会把架构设计的越来越复杂，导致开发技术延期。 　　业务知识：设计模式是和业务有非常密切的关系，如果连业务都不懂就设计，一定会失败 　　UML理论以及工具：这个是设计的基本要求，千万不要用excel画个框架就说这是架构，一个完整的设计需要包括UML图、业务流程图、用例图、活动图、组件图、类图； 　　架构模式：也就是上文提到的一些经典架构模式 　　重构：不是所有不好的代码都要重构！重构不一定可以解决所有问题！《代码重构》书中说，重构不单出是一种开发期与代码回顾期所使用的方法，而是涉及与编码的思想指导！ 　　代码质量：建议直接使用官方的规范，要在开发过程中对于烂代码零容忍，架构师参与到核心模块的开发，实施把控代码质量，当时看不出好处，但好处一定是长久的。 　　3.5 深入业务 　　上面内容都掌握了，也不是一个好的架构师，技术知识手段是工具，要做出好的产品一定是对产品本身和业务都有深入的理解的。当我们什么时候认识到了技术只是服务产品的工具的时候，就是成长的时候。 　　业务非常模糊的话，非常容易到开发完了才发现问题，大家也应该都知道会导致牵一发动全身的后果。 　　四、架构师的书籍 　　看了回答中的方法论很多了，这里不多赘述了。推荐几本我认为最最最实用的书： 　　《设计模式》这本书真的是不懂阶段的人领悟完全不一样，这本书可以帮助我们把复杂的问题简单化，第一遍通读，之后可以当成工具书。 　　《Java编程思想》如果你还没有面向对象的概念，或者你要提升面向对象的设计能力，这本书永远都是我最推荐的 　　《Refactoring》重构方面的书，这里面的说到的意识和思维都是可以用于架构设计 　　《eXtreme Programming》大部分内容都在讨论方法，但是书中把架构师需要锻炼的控制和变化范围与程度分析的非常透彻。 　　五、架构师的知识领域 　　整理到这里发现说的有些乱，总感觉有不足，欢迎批评指正。 　　5.1 架构的方法论 　　面向过程、面向对象、面向方法、面向组件、面向服务等方法论，每一种方法的点都不同。 　　面向过程：功能分解（自上而下，每层细化）需要的是流程、函数。库文件；缺点是业务流程强耦合，复用性差，在修改代码的时候牵一发动全身，语言代表：C和Basic 　　面向对象：数据结构和算法在这里是对象，实现任何类的对象都具有一定属性和操作。公式：程序=对象+对象+对象，对象=数据结构+算法。有点就是一切都是对象，抽象复用，灵活。代表语言：Java、C#。缺点是对象很容易把简单的问题也复杂化。 　　面向组件：可以重用多个类和组件，面向对象我们可复用的是一个类，那么组件就是一个小程序，所以效率更高。但是面向对象的限制是对象之间的互相依赖，去掉这个限制的好方法就是组件。公式=组件+交互，设计重点视功能模块。缺点是增加了组件维护和升级成本，代表框架OSGI。 　　面向方面：通用需求功能从没关系的类中分离，一旦发生改变就没必要修改很多类。也就是将通用功能与业务分离，代表框架Spring AOP。 　　面向服务：这个体系目标就是软件代理交互中获得松散耦合。特征就是松散耦合，位置透明，协议独立。公式：系统=服务+交互，也就是独立部署，优点有效利用资源提供高性能。代表框架：Dubbo，Zero Ice，Spring boot 　　5.2 系统拆分 　　业务复杂，复杂系统的情况下需要对系统进行拆分，大系统拆分小模块，进行模块开发。 　　垂直拆分：自上而下的拆分是把系统—子模块—模块—功能—接口分别拆分。 　　水平拆分：是按照逻辑拆分，将系统进行横向切分之后按照层级进行部署，比如接入层、服务层，资源层。但是逻辑拆分是不考虑实际部署的，后续的部署可能也是分开部署横向拆分的要点在于每一层都有自己的重点和边界。 　　5.3 架构基本原则 　　场景化：避免过度发挥 　　抽象：具体的事物进行抽象，将共有行为抽象为接口，将共有逻辑抽象为基类； 　　高内聚：部件的内部关系，行为进行封装，不暴露接口 　　松耦合：部件之间依赖关系，可以通过接口和异步实现解耦 　　职责：可以按照职责进行拆分 　　分层架构：将系统进行物理层和逻辑层拆分 　　通用专用：通用不见和专用部件进行拆分，降低耦合度 　　平衡：这就是边界和变化问题，需要学会衡量取舍，权衡需求和技术，约束和质量还有成本问题，这是架构师的第一方法论。 　　其他：SOLID 　　暂时更新到这里，后面还有设计模式、架构模式、视图、架构模型、静态模型等等内容；如果有人看在更新，匆匆写了一个上午。希望给到真正学习的朋友们帮助，点❤追更。可能你还需要：2021年全新Java学习路线图 2021年黑马程序员前端学习路线图 2021年软件测试全套学习方法和资源整理 为什么大公司要用微服务？不用就是落后了吗？ 　　我是黑马程序员，认准知乎蓝V @黑马程序员 。学习编程路上有任何问题都可以评论私信，有问必答。有时候问的太多会错过，麻烦多私信一遍~（不愿每一个程序员孤寂的成长）