A. 程序员删除流氓软件
电脑在网上下载一些东西时经常被捆绑下载很多流氓软件，导致电脑是不是跳出一些弹窗广告，烦不胜烦。经过努力奋斗终于把流氓软件都删除了，下面介绍几个删除流氓软件的经验。
1、如果软件不是安装在C盘，可以使用bitloacker给D盘加密，这样开机就不能自启，就可以删除了。不过bitlocker是windows专业版才有。
2、按win + R打开运行，输入gpedit.msc打开它,
在这里插入图片描述
如果你的windows是家庭版，会报错gpedit.msc找不到,
这时需要自己写脚本打开pgedit.msc功能，步骤如下：
先运行notepad，
在这里插入图片描述
输入如下代码：
@echo off
pushd “%~dp0”
dir /b C:\Windows\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientExtensions-Package~3*.mum >List.txt
dir /b C:\Windows\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientTools-Package~3*.mum >>List.txt
for /f %%i in (‘findstr /i . List.txt 2^>nul’) do dism /online /norestart /add-package:“C:\Windows\servicing\Packages%%i”
pause
在这里插入图片描述
另存为gpedit.cmd文件，
在这里插入图片描述
以管理员身份运行，等待运行完成即可。
在这里插入图片描述
然后就可以使用gpedit.msc打开软件策略了。
在这里插入图片描述 选择其它规则，
在这里插入图片描述
右键新增哈希规则（散列规则），
在这里插入图片描述
点击“浏览”选择你要禁止自启动的项，比如exe、dll等应用程序，点击确定，然后重启电脑，你的流氓软件就不会开机自启动，就可以删除了。
3、如果有一些dll无法通过gpedit.msc禁止，比如LDSGameMaster文件夹下SpSvc.dll每次开机都被其它进程启动，任务管理器根本找不到该进程，gpedit.msc也禁止不了。这时有个很简单的办法，直接修改dll的后缀，比如在dll末尾加apk，然后重启电脑，这时因为dll被修改后缀，进程无法链接到它，这个dll就可以被删除了。
4、有些软件卸载后还有一些功能残留，比如iPDF，这时可以先卸载iPDF，然后运行regedit打开注册表，然后按ctrl + F搜索iPDF，把所有包含iPDF的项全部删除即可。
5、有些文件夹是空的，删除时弹出文件正在其它程序中打开，这是流氓软件把可执行程序隐藏了，可以下载Unlock打开该文件夹并删除它，也可以使用360进行删除
B. 工作一到五年的Java程序员遇到瓶颈应该如何提升
工作了5年的Java程序员，该如何提升,做了3~5年Java开发，你已经积累了不少项目经验，扩宽了技术广度，也许已发力成为团队管理者。到了这个阶段，大家却常有这种感受：感觉自己卡在瓶颈进步缓慢，技术水平很难像早期一样实现大幅突破？
其实大家往往忽略了这一点——提升自己的架构认知（工作5年左右程序员必须重视架构认知的提升，这会很大程度上推动你今后的成长）。架构的本质在于面对业务场景给出优雅的解决方案，使得业务能够快速迭代和持续交付，从而达到降本增效的目标。提升架构认知高度，就像达克效应所描述的一样，要敢于从愚昧之巅跳到绝望之谷，通过爬升开悟之坡，从而达到架构认知的巅峰时刻。到达巅峰时刻也就掌握了架构背后设计的哲学，面对具体业务场景在架构层面你便能够轻松应对，以无招胜有招。
提升架构认知，要紧抓3个关键点：业务洞察力、技术视野、原创力（执行力）。
1.业务洞察力是技术战略层面的问题，在当下能够做出合理的判断，清楚公司做什么事情收益最大；
2. 技术视野即技术选型能力，是技术战术层面的问题，在清楚做什么事情后，需要进一步解决怎么做的问题，也就是能够给出合理的技术选型方案：是完全基于开源的方案，还是基于开源二次开发的方案，还是完全自研的方案；
3. 原创力（执行力）是技术落地执行层面的问题，一旦技术设计方案确定后，需要能够快速Rush完成。
这3点层层递进，最重要的是先把技术战略问题思考清楚，然后再进一步解决技术战术问题，最后是快速落地执行的问题。
工作5年左右的程序员，在原创力（执行力）层面比较有竞争力，往往欠缺技术视野以及业务洞察力。后面2点更加重要，这2点解决的是架构设计哲学问题，是架构师能够持续拥有竞争力和影响力的立身之道。
举个场景的例子来详细说明：一提到分布式锁问题，大多数人想到的方案是基于Redis的Master-Slave模式来实现。这个实现方案行不行？分布式锁本质是一个CP需求，基于Redis的实现是一个AP需求，乍一看基于Redis的实现是无法满足的。脱离业务场景来谈架构都是耍流氓。
从技术战略的需求层面来看，如果分布式锁在极端情况下获取锁的不一致，社交业务场景能够接受，那么基于Redis的实现是完全可行的。如果业务是交易场景，分布式锁在极端情况下获取锁的不一致性无法接受，那么基于Redis的实现方案是不可行的。在锁强一致性的场景下，需要采取基于CP模型的etcd等方案来实现。