使用eclipse-juno新建的maven项目，使用过程中无任何问题，但是换了eclipse-luna版本后，导入同样的maven项目，则报javax.servlet.jsp.JspException cannot be resolved to a type错误；这可能是新版本eclipse的bug导致。 在网上找的解决方案是在你的项目中加入jsp-api.jar和servlet-api.jar包，这两个包来源于tomcat的libs目录中，但是会出现一个问题，项目打包发布的时候也会将这两个jar打包出去，这时候发布到tomcat中后tomcat可能启动失败，同时你的jar包可能和tomcat中的jar版本不一致等情况。 解决方式：右键你的项目--properties选择Targeted Runtimes，选择你的运行环境，我选择Apache Tomcat v7.0，Apply--OK。 from:https://www.cnblogs.com/sharpest/p/6017983.html
View Details1.运行“gpedit.msc”（win键 + R键）。 2.展开计算机配置下的“管理模板”，选择“windows组件”。 3.找到“Windows Defender 防病毒程序”。 4.找到并且双击“关闭Windows Defender 防病毒程序”。 5.选择“已启用”，确定即可！ from:https://zhidao.baidu.com/question/1673371693997231947.html
View Details最受欢迎的国产开源项目都是什么模样？选用什么开源协议？使用哪种语言？实现了什么功能？ 我们选取了码云 Gitee.com 平台 144 个优质开源项目，为你深入剖析国内 Top 开源项目。 （项目选取标准：入选 GVP——码云年度最有价值开源项目计划，或获得超过 1000 个 star。） 1.开源协议（license）分布——宽松型是首选 1.1 宽松式协议是首选，Apache-2.0 占比 45.14% Apache-2.0 是码云Gitee 上开源作者的首选，占到了 45.14%，JFinal 、t-io、iBase4J 等正是采用此协议。另一个则是 MIT，占比 17.36%，zheng、layui 等正是此类代表。 宽松式协议允许用户任意使用软件，从而确保大家能从软件中得到最多的利益。 Apache-2.0 是宽松式协议（permissive license）的代表，它还包含了贡献者向用户提供专利授权相关的条款，使用 Apache-2.0 的知名软件有 Android、 Apache、Swift 等。 MIT 协议几乎对用户没有什么限制，只要保留版权声明和许可声明且不要求开发者承担责任，这也成为其深受欢迎的重要原因，国际上使用 MIT 协议的知名软件有 JQuery、.NET Core 、Rails 等。 1.2 限制式协议 LGPL、GPL、AGPL 紧随其后 LGPL、GPL、AGPL 这三项协议的采用占比为 2.78%、8.35%、1.39%，它们的限制性由弱到强，分别规定： 如果项目采用动态链接调用 LGPL 许可协议的库，项目可以不用开源； 如果项目包含了 GPL 协议的代码，那么整个项目都必须使用 GPL 许可协议； 如果云服务（即 SAAS）用到的代码是 AGPL 许可协议，那么云服务的代码也必须开源。 限制式协议的初衷是帮助开源项目获得成功，从条款上进行了详细的限制，防止部分开发者修改代码却不回馈社区的情况。但凡事皆有两面，高复杂性的许可协议，不仅限制了他人，也会限制作者自身，或许这种风险正是从限制式协议到宽松式协议转变的原因。 1.3 对开源许可协议的认知和应用有待提升 在参与统计的 144 个 Top 开源项目中，未选择开源协议的项目占到了 24.31%；在码云推荐过的 7000 多个开源项目中，未选择开源协议的占比 43.95% ；而在码云上所有的开源项目中，这一数据扩大到了 77.12% 。 规则与约束是实现真正自由的前提，开源崇尚“自由、开放、分享”，更需要大家自觉遵守规则，才能实现更高的效率。 码云在此呼吁广大开源作者善用开源协议，让开源项目的发展更加规范和健康，关于如何选择开源协议，可以参考这里。 2.编程语言分布——Java 一骑绝尘 2.1 Java 类项目占据半壁江山，高达 65.73% Java 类编程语言在 Top 开源项目中可以说遥遥领先，占到 65.73%。包括了 guns、nutz、jeecg 等优质的开源项目，此类框架式的项目受到了众多开发者的喜爱。 Java 到 2018 年已经有 22 年的历史了，它在实用性、性能、向后兼容性以及跨平台性等方面都有着优秀的表现，在技术快速更迭的今天，往后的十年甚至二十年 Java 是否能一直保持这种优势呢？让我们拭目以待。 2.2 PHP […]
View Details开源中国问答区新栏目“OSCHINA 问答合集”上线啦，本期收录了 5 月高热度的问题及回复（吐槽），希望能让你有所收获~！ 本期问答合集收录的问题，动辄就是“千万”级别的场景，这让大家“面试造火箭”的那些本领终于可以有用武之地了。 而关于程序员职业生涯方面，有妹子问到“女生做架构师是否靠谱”，我们热心肠的 oscer 岂会袖手旁观？ 不多说了，各位接着阅读大家的精彩回答吧~！ 进入问答区： 你可以在技术问答版块畅聊技术 你可以在职业生涯版块寻道解惑 你可以在IT大杂烩版块和大家谈笑风生 我们希望： 这里可以成为一个能让大家有所收获的地方。因此，这里拒绝攻击、拒绝谩骂、拒绝无脑黑。 这里可以沉淀大家各种的技术问题。无论是新手的基础问题，还是高端玩家的资深问题，都是有价值的。 这是一个更纯粹讨论技术的地方，能给程序员提供一片友好交流的清净之地，不懂的可以在这里寻找帮助，懂的可以在这里帮助别人。 总之， 在这里你可以向所有人提问。 反正你的问题可能会没答案。;-) ==========分割线========== 开源中国技术问答 @飞扬的梦 ：关于Java高并发的问题 我有一套系统，高峰期每秒钟约有1万人下单，平均每个用户下28件商品，系统延迟要求在30毫秒响应客户。 请问，我要怎样做才能保证库存不会超，重点是30毫秒内客户端就要响应。实测使用redis，如果集群的话，会导致库存超，不集群的话，redis没过一会就崩溃了，有时间数据会出错。 数据库用mysql的，写入没有太多的问题。现在主要问题是在redis性能上。 >>>@公孙二狗 从问题来看，楼主应该经验不怎么丰富，但是能有这么牛逼的业务的公司，轻轻松松拿出几个亿来开发这种项目应该不是问题，大把的人才，怎么可能到论坛找方案呢。 >>>@Storm-Cai 这个问题归根到底还是库存控制。下单过程、查商品校验啥的都没问题，redis集群能解决问题。 库存保证如果需要时间响应优先，则可以采用redis集群中原子操作，每种商品做一个k-v的库存数量，下单该商品就库存减1，如果28件商品需要写28次redis，可以并行去写。库存数量以redis中为准。 追问：公司上一代架构是这样做的，但是redis性能上限，导致每秒最多只能28万订单入库。现在改了架构了，不过变成单机版的。我在寻找一下，既可以集群高可用，速度又快的方案。 哦，看明白你的意思了。你是说即时采用库存数量全部放redis，每个redis实例存一个商品库存，一共28个商品实例，一秒也只能有28WTPS？可以这样，采用内存分区数据分段校验。以上是说，不存redis了，你项目不是集群的么，跑多少个实例，库存就分多少片。假设商品库存10000个，你跑了四个服务，那么每个服务就只能下单2500个成功，前端负载均衡策略采用轮询。 这样的方案你来多少都没啥问题，前提是预先要把库存设好，在启动抢购这类活动前，要保证每个服务进程内数据都对，不然会导致库存对不上。 假设商品A有库存10000个，你跑了四个服务，进程内每个库存数量就是2500个，采用原子递减去减库存。异步同步数据到数据库就是了。这种方案也是我采用的方案，效果杠杠的。有个不好的地方就是活动进行中服务绝对不能宕机……….. >>>@keepthinker 采用Redis Cluster或自己搭建逻辑集群（自己做key哈希分散到不同节点），采用计数器分片（Redis incr操作），假如分片100个，总共100w个商品，那么每个分片计数器最大值为10000，假如有进程计数器对加1后超过最大值则认为没库存，一个redis 8W TPS，假如计数器平均分散到每台Redis机器，就能最多支持100 * 8W TPS的分布式计数器，Redis数量越多，那么就能无限逼近800W TPS。 对于这种写入峰值高的订单入库要求，那么当然得采用高可用队列进行削峰限流写入MySQL数据库。 >>>@Chet_W hash分散，将不同的商品和交易信息存在不同的redis >>>@抢小孩糖吃 应该做流量控制，通过流量控制分散库存请求到具体的Cache，并对竞争做队列处理，消耗库存。多一步流量控制解决具体导向哪个队列服务，降低多节点对单一Redis的竞争。 @emo奋斗 ：我有一个打击物流、电商假货的app思路，请大神们提提意见 1.每个产品生产出来自动生成一个独立二维码； 2.如果有包装，每个包装（单个或集合包装）也自动生成独立二维码； 3.打包（单个或集合打包）或者拆包时对包装和产品进行关联或者解除关联； 4.产品每到一个环节的关联或解除关联，通过二维码记录时间、地点（精确定位）、主要动作（流转、打包、拆包）、关联主体； 5.每一次关联都对每个app中已记录信息进行更新； 6.下一各关联主体关联产品必须获取上一个关联主体的授权； 7.流通环节关联主体均必须获得首端主体的授权方可注册，终端环节具有查询权限，可获取所有产品流通关联信息； 8.只要保障首端不出问题，保证所有被授权流通环节出货均为正品。 >>>@程序猿猴 产品溯源系统， 你本质就是解决信任问题，这正是区块链解决的问题。 随之带来的就是复杂的操作流程和高昂的成本。 如果产品要溯源的话，这个问题就复杂了，比如说一件衣服的溯源吧： 1. 涤纶/棉原料溯源 2. 涤纶/棉制作原料溯源 甚至还要往下追溯好几层，成本可观 现在物流体系的各个系统其实监管都还比较严格，想要造假需要几个部门的联合操作，一个物流系统可能由：omc，tms，wms等系统组成，如果想调换一个货物，则需要仓库工作人员和系统操作人员联合操作才能实现。 >>>@苍暮之星 这一套方案可行的前提是没有内鬼，这个只能防外人，不能防止业务流上的工作人员舞弊。而这套方案偏偏又是防内鬼的，不然谁能够在物流途中更换商品？没有可行性啊。再说了，像顺丰等成熟的物流体系，人家内部本身就有这类制度，甚至有时候会故意在包裹里塞上标识物，现在出问题的都是收件环节和发件环节，也就是最小的收发点会出这种换货的可能性。 追问：从生产出来已经开始读取产品信息了，并且每个环节的有效读取和非有效读取都是有记录的，而且有效读取信息需要专门授权。至于最后的销售环节，存在掉包产品的可能性，不过正常来讲，只能通过销售代理单位销售。所以，一方面从非代理单位购买本身就难以避免假货；另一方面，流通信息可随时记录、查询，一物多卖很容易被查出；再者，在以上两个条件下，最后销售环节更换商品的代价太大，会被取消资格。 >>>@飘摇清风 感觉像类似mes的应用，人工、管控成本过高，从成本上考虑不一定能行。不知道您是否知道用假的400电话验证假货的防伪码，一条龙服务，价格也不高，别指望每个人都会去官网验证。 追问：主要的问题是，信息关联共享。400验证码是可以复印的，这个你复印下来，只要扫描就知道流向。这个我想是适用于稍微高端的产品，买个棒棒糖就不至于了。而且，在我看来没有什么运营成本。 运营成本只是成本中的一种，而我提到的人工成本不只运营人工，还包括生产人工成本、仓储人工成本。对于高附加值产品可以忽略这点成本，而对于那些低附加值的，搞这套东西只会死得更快。 我举的400例子只是想说，对于量大、火爆产品，只要利润够高，造假者能生生模拟出一套验证机制，这样你这个追溯机制直接就能跳过了。 所以说你这机制书面意义比较大，实用性还需要再研究研究。 @Death黎明 ：除了spring我们还有什么？ 最近在公司修改了几个旧的项目，发现这几个旧的项目都没有使用任何的框架，这对长期使用spring的我感觉到十分的吃力，艰难的完成任务后心中浮现除了这个问题： 除了spring我们还有什么？ spring可以极大的提高我们的开发效率，这使得在培训班出身的我的眼中spring几乎成为了java的代名词。 我感觉这很不对劲，希望去学习一些可以抛开spring的东西，希望大家给我些建议。 >>>@很拽De土豆 现在主流的java web框架，一套是以servlet为标准的spring,struts,jfinal等框架，目前主流基本都是这个。还有其它的比如actframework,playframework等无servlet的框架。 如果你使用java的话，基本离不开这2种类型。如果抛开spring的话，你可以选一种你自己喜欢的类型，自己封装一个简单的框架，理解学习，比如你可以看看smartframework，它从无到有讲解怎么写一个简单的java web框架。 […]
View Details