Java

როგორ გავხადოთ სტეკი უნივერსალური არა მხოლოდ Integer-თან მუშაობისთვის, არამედ String და პერსონალიზებული ობიექტებისთვისაც?

რა უნდა გაითვალისწინოს წარმოებაში დიდი სართულის ინდექსის შექმნისას?

წერეთ თქვენი საკუთარი კლასი, რომელიც ახორციელებს სტეკს, მეთოდებით push, pop და peekMax, რომელიც აბრუნებს სტეკში მაქსიმალურ ელემენტს O(1)-ში.

რატომ არის საჭირო SELECT FOR UPDATE, არა სინქრონიზებული? და რატომ პესიმისტური ბლოკირება, ოპტიმისტური არა?

რა უნდა გავაკეთოთ, თუ processFile ვერ შესრულდება ტრანზაქციის დადასტურების შემდეგ?

რატომ მოხდება StackOverflowError, თუ ადგილობრივი ცვლადები არ არსებობს? რა გამოიწვევს მეხსიერების შევსებას?

რატომ არ შეგვიძლია უბრალოდ ერთი max ცვლადი გამოვიყენოთ მეორე სთეკის ნაცვლად?

Бар სისტემა, რომელიც მომხმარებლებს საშუალებას აძლევს მუშაობა ფაილებთან ბრაუზერში. სტანდარტული ტექნოლოგიური სია: Java, Spring, React, Postgres. ფაილები ინახება ფაილური სისტემაში ბექენდზე, ფაილების მეტადონები მონაცემთა ბაზაში. გუნდი განახორციელა ფუნქცია: @Transactional public void process(String oldName, String newName) { Long id = exec("select id from file where name='" + oldName + "'"); // მონაცემთა ბაზაში შეკვეთა processFile(oldName, newName); // ფაილის სახელის შეცვლა დისკზე exec("update file set name='" + newName + "' where id = " + id); // მონაცემთა ბაზაში შეკვეთა }

შეგვიძლია ოპტიმიზაცია გავაკეთოთ მეხსიერებაში, რომ x2 მოხმარება არ იყოს?

Backend-ი არსებობს, მომხმარებლის ინტერფეისიც. ტექნოლოგიური სია სტანდარტულია: Java, Spring, React, Postgres. მოსაზრება: შექმენით REST წერტილი, რომელიც უნდა მიიღოს მონაცემები 3 წყაროსგან და გადმოსცეს UI-ს, მაქსიმალური შესაძლებლობის და მინიმალური პასუხის დროის უზრუნველსაყოფად (მაქსიმუმ/მინიმუმ კრიტერიუმები ჩვენი კონკრეტული პირობების მიხედვით, რადგან არსებითად არ არსებობს ჯადოსნური გადაწყვეტა და საჭიროა კომპრომისის მოძებნა). ცნობილია, რომ ამ წერტილისთვის მოსალოდნელი პიკ RPS იქნება 200. მომწოდებლების შესახებ დეტალები: 1. წყარო - ჩვენი მონაცემთა ბაზა, შეკითხვა დაახლოებით 15 წამი გრძელდება. 2. წყარო - დაკავშირებული REST სერვისი, 100 RPS-ის ქვეშ 2 წუთამდე დეგრადირებს, ნორმალურ რეჟიმში პასუხობს 5 წამში. ამ წყაროს ქცევას ვერ შევცვლით. 3. წყარო - დაკავშირებული REST სერვისი, შემთხვევით (სპეციფიკური ნიმუშები არ არის გამოვლენილი) პასუხობს 503 შეცდომებით, ნორმალურ რეჟიმში პასუხობს 10 წამში. ამ წყაროს ქცევას ვერ შევცვლით.

რომელ ტიპის ინდექსი გამოიყენოს შუა ან ბოლო სტრიქონის ძიებისთვის (LIKE '%ტექსტ%')?

დაწერეთ ძალიან მარტივი მეთოდი, რომელიც მუშაობის დროს გამოიწვევს StackOverflowError-ს.